On Thu, 13 Aug 2015 20:40:37 +0200 Jesper Dangaard Brouer <bro...@redhat.com> wrote:
> On Thu, 13 Aug 2015 10:49:50 -0700 > Stephen Hemminger <step...@networkplumber.org> wrote: > > > On Thu, 13 Aug 2015 19:01:05 +0200 > > Phil Sutter <p...@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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
