Re: [PATCH 0/2] net: introduce IFF_NO_QUEUE as successor of zero tx_queue_len

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 13 Aug 2015 20:40:37 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:

> On Thu, 13 Aug 2015 10:49:50 -0700
> Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> > On Thu, 13 Aug 2015 19:01:05 +0200
> > Phil Sutter <phil@nwl.cc> wrote:
> > 
> > > Up to now, drivers being aware of the above applying to them set
> > > dev->tx_queue_len to zero to indicate no qdisc should be attached to the
> > > interface they drive and the kernel reacts upon this by assigning the noop
> > > qdisc instead of the default pfifo_fast. This implicit agreement though leads
> > > to an inconvenient situation once a user tries to attach a real qdisc to these
> > > devices, as the formerly special tx_queue_len value becomes a regular one,
> > 
> > So this is a workaround for user ignorance by introducing kernel API complexity.
> > Before user sets qdisc, why don't they set tx queue length?
> 
> Please don't insist on keeping this broke interface... how should users
> know that BEFORE adding a qdisc they MUST change the _device_ tx queue
> length (not zero).

Before setting any qdisc, they should set queue length anyway.

>  Getting "back" to the original state, they MUST
> change the device tx queue len back to zero BEFORE deleting the qdisc,
> such that when assigning the default queue qdisc the system detects
> this device can work without a qdisc.  Changing the tx queue len to
> zero after the qdisc is deleted will have not effect. 
> 
> Listen to the description, that interface is broken. The kernel really
> needs to hide these details from userspace.
> 
> It even allows you to misconfigure the kernel, by tricking the kernel
> into assigning noqueue to physical devices that really need it.

But adding a flag risks breaking external scripts.