Polling with multiqueue support

[Fabien Thomas]

On Feb 24, 2011, at 4:39 PM, Ryan Stone wrote:

> Ah, you've anticipated me.  This is just the kind of thing that I had
> in mind.  I have some comments:

Thanks for your feedback.
You pushed me from my laziness to explain the patchset on the ml.  :)

> 
> - Why allocate the poll_if_t in ether_poll_register_?  If you let the
> driver allocate it you don't have to worry about failure.  And the
> driver can embed it in its rx_ring so it doesn't have to worry about
> malloc'ing it anyway.  We can also put one it struct ifnet to preserve
> the traditional ether_poll_register interface.

Good point. I take it to my TODO list

> 
> - I'd personally prefer it if ether_poll_register_mq didn't require a
> struct ifnet to be passed in.  Nothing seems to use the ifnet anymore
> and here at $(WORK) we have some non-ifnets that actually register a
> polling handler.  Currently they just allocate a struct ifnet to make
> the polling code happy but I don't see any reason to require one.
To be sure to understand using context + queue id only as identifier for the mq part 
and grab the ifp from the context in the driver ?
That seems ok to me if it block case where you dont have ifp.

> 
> - Also, I don't quite understand why the separate TX step is necessary now.

It helps because TX is done only when every interface (on this taskqueue, 
cross taskqueue will require sync point) have processed packets to completion.
It can also help for the fairness between interface on the same taskqueue to rotate faster to the next if.
This is not required and can be used or not driver per driver (if not used everything can be done on RX).

There is also one fix pending for the compatibility interface: the packet per round need to be increased because there is no feedback loop on the old API.

Fabien