Re: [RFC] split NAPI from network device.


Actually, Ben did you determine if this scheme works for your device
which has a single interrupt source yet multiple queues? There is one
driver that, during the conversion, I noticed has a similar issue.
One driver, netxen, has multiple channels, so it just passes in
"bugdet / NUM_CHANNELS" as the quota so that one channel could not
starve the others.


The device has a single interrupt though that interrupt at least can
tell you which queues need servicing. It can't mask the interrupt per
queue though, which is the main issue.

So while I think this scheme would work (the driver, ibm_emac, currently
uses a fake net_device and that sort-of works, budget is set a CONFIG_*
time though, I'm sure that can/needs to be improved), I've been
wondering all along if I could do something smarter by doing some
interrupt soft-disabling instead, though I have to get my head around
properly kicking softirqs from task context (if I need to re-trigger
from a enable_*() call occuring at task context).

I'm travelling at the moment, so I won't be able to have a serious look
for a little while though.

Cheers,
Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC] split NAPI from network device.
    ... which effectively turns it into a single interrupt ... for multiple queues as far as NAPI is concerned. ... NAPI interfaces and makes driver maintainence harder than it would ...
    (Linux-Kernel)
  • Re: Changes in the network interface queueing handoff model
    ... The main complication I've seen is when a driver needs to process multiple queues of packets things get more involved. ... With the current scheme you have two separate queues and the start method handles prioritization by polling the mgt q before the data q. ... If instead the packet is passed to the start method then it needs to be tagged in some way so the it's prioritized properly. ... Indeed, it does, but structurally, SLIP is split over the link layer and driver layer, which I had forgotten. ...
    (freebsd-arch)
  • Re: Changes in the network interface queueing handoff model
    ... The main complication I've seen is when a driver needs to process multiple queues of packets things get more involved. ... With the current scheme you have two separate queues and the start method handles prioritization by polling the mgt q before the data q. ... If instead the packet is passed to the start method then it needs to be tagged in some way so the it's prioritized properly. ... Indeed, it does, but structurally, SLIP is split over the link layer and driver layer, which I had forgotten. ...
    (freebsd-net)
  • Re: TX Multiqueue?
    ... around the process of queuing packets to the device was a performance issue ... Having multiple queues, even for a single class of traffic may enable enough ... additional concurrency in the driver to increase throughput. ...
    (freebsd-net)
  • Re: TX Multiqueue?
    ... around the process of queuing packets to the device was a performance issue ... Having multiple queues, even for a single class of traffic may enable enough ... additional concurrency in the driver to increase throughput. ...
    (freebsd-current)