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). 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. -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- 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
