[Top] [All Lists]

Re: [RFC] netif_rx: receive path optimization

To: Stephen Hemminger <shemminger@xxxxxxxx>
Subject: Re: [RFC] netif_rx: receive path optimization
From: Eric Lemoine <eric.lemoine@xxxxxxxxx>
Date: Thu, 31 Mar 2005 23:43:27 +0200
Cc: hadi@xxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gc8PtgpzrGImDCA6ttxhH1CO0TMfG1gk1NN8Ca1uBWoyRC5Bavt/RQIbQRUF+KLK1bDmypkuxqXW23jV1ITxV77u88R8LyN4e4twg+jLzMrYPip7WOjx8ry1vJPJxsSWTwQiWbJPzwwD/1KKqsDlbajqO/YlA757O0s/ekGYsHY=
In-reply-to: <20050331131707.69f451ea@xxxxxxxxxxxxxxxxx>
References: <20050330132815.605c17d0@xxxxxxxxxxxxxxxxx> <20050331120410.7effa94d@xxxxxxxxxxxxxxxxx> <1112303431.1073.67.camel@xxxxxxxxxxxxxxxx> <20050331131707.69f451ea@xxxxxxxxxxxxxxxxx>
Reply-to: Eric Lemoine <eric.lemoine@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
> > > Here is another alternative that seems better than the earlier posting. 
> > > It uses
> > > a per device receive queue for non-NAPI devices.  The only issue is that 
> > > then
> > > we lose the per-cpu queue's and that could impact the loopback device 
> > > performance.
> > > If that is really an issue, then the per-cpu magic should be moved to the 
> > > loopback
> > > device.
> > >
> >
> > The repurcassions of going from per-CPU-for-all-devices queue
> > (introduced by softnet) to per-device-for-all-CPUs maybe huge in my
> > opinion especially in SMP. A closer view of whats there now maybe
> > per-device-per-CPU backlog queue.
> Any real hardware only has a single receive packet source (the interrupt 
> routine),
> and the only collision would be in the case of interrupt migration.  So having
> per-device-per-CPU queue's would be overkill and more complex because
> the NAPI scheduling is per-netdevice rather than per-queue (though that
> could be fixed).
> > I think performance will be impacted in all devices. imo, whatever needs
> > to go in needs to have some experimental data to back it
> Experiment with what? Proving an absolute negative is impossible.
> I will test loopback and non-NAPI version of a couple of gigabit drivers
> to see.

Just a naive question : why at all trying to accelerate netif_rx?
Isn't NAPI the best choice for high performance rx anyway?


<Prev in Thread] Current Thread [Next in Thread>