On Thu, 31 Mar 2005 23:43:27 +0200
Eric Lemoine <eric.lemoine@xxxxxxxxx> wrote:
> > > > 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?
It was a side-effect of trying to clean out the dead code leftover from
removal of fastroute and other old experiments. netif_rx still gets used
for loopback and people do benchmarks on loopback. Also, NAPI doesn't
work for all cases like layered devices and devices like wifi that need to
receive packets when the network device is "not running".