Re: [PATCH] netdev: handle setting transmit queue length on active device.

[Patrick McHardy <kaber@trash.net>]

Stephen Hemminger wrote:
> On Wed, 18 Mar 2009 18:15:38 +0100
> Patrick McHardy <kaber@trash.net> wrote:
> 
>> Stephen Hemminger wrote:
>>> Some virtual devices like VLAN's or bridges by default have not transmit queue.
>>> In order to do queuing disciplines on these devices a queue must be added
>>> by setting transmit queue length. The kernel allows doing this at any time, but
>>> setting the queue length value is not enough. Setting the queue length does
>>> not create the transmit queue (going from 0 to non-zero) or destroy it
>>> (setting to zero); the queue is only created (or destroyed) when device
>>> comes up (or goes down).
>>>
>>> This patch handles this be doing the necessary activations.
>>>
>> That seems quite heavy-weight in case of hierarchical qdiscs, it will
>> walk and reset the entire tree and looses all state, including packets
>> as a side effect. Its also a bit inconsistent since it only affects
>> the default pfifos at the root, not the inner default qdiscs if I'm
>> not mistaken.
>>
>> A less intrusive way would be to simply use dev->tx_queue_len directly
>> in pfifo when no limit is configured. That would require to make a
>> runtime decision for each packet though. Two more alternatives:
>>
>> - add a special pfifo variant that always uses tx_queue_len. Duplication
>>    comes down to pfifo_enqueue (a few lines) and a new struct Qdisc_ops
>>
>> - if you really only care about the root, reconfigure it explicitly
>>    using fifo_set_limit()
>>
> 
> The problem is when setting limit to 0 to force noop and setting it
> to non-zero to force pfifo_fast back again.


I'd suggest to simply attach a pfifo qdisc with an explicitly
configured limit to activate queueing on virtual devices.