Re: netif_stop_queue() and multiple hardware queues

[Jeremy Jackson <jerj@coplanar.net>]

David Miller wrote:
> From: Jeremy Jackson <jerj@coplanar.net>
> Date: Sun, 02 Jul 2006 22:36:03 -0400
> 
>> I propose that this is an architecture/framework/API issue that the 
>> Linux core networking code should be dealing with.
> 
> Proposals are worthless if nobody wants to do the work to actually
> implement the proposal.
> 
> Your tone seems to suggest that you feel if you propose something,
> someone will just jump out of their seat and implement your proposal.
> 
> That's not how this works :)

I apologize for the tone.  I *am* interested working on this.  I'm just
surprised nobody has jumped out of their seat to do it :)

I have changed a line or two of kernel code but am by no means an
expert, so I guess I was hoping for some kind of feedback about the
proposal.  I guess submit a patch for discussion?  If it's gross I guess
that would generate some feedback.

What's the best Git tree to base this on?  (maybe it's name means make
svn and and cvs users feel like a stupid git?)

In the current 2.6 network driver interface, the TX path seems to be
based on mydev->hard_start_xmit().  The device driver initiates flow
control with netif_stop_queue().

netif_stop_queue() and other functions (macros in netdevice.h) touch
mydev->state, the bit __LINK_STATE_XOFF:

netif_schedule()
netif_start_queue()
netif_wake_queue()
netif_stop_queue()
netif_queue_stopped()

There is only one queue now, implied by default.  Adding a "hwqueue"
parameter to all of the above would be a start.

It would be ideal if mydev->xmit_lock could be separated out, one for
each hwqueue.  A quick hack to implement this would be for the device to
set the mydev->features NETIF_F_LLTX, and implement per-queue locking.

Teaching qdiscs to use the multiple queues looks tricky in comparison, a 
quick hack might be to have prio's bands map 1:1 with the hardware queues.

Regards,

Jeremy