tree 96e2ab31bce5b78eee48db5658a1a3105ea4519a
parent 8f8ff9135b28a7560a5627aceaf289e3f0d4cd64
parent 4b469955685d58c2f8198bf817fc661600b7e3d0
author David S. Miller <davem@davemloft.net> 1439837425 -0700
committer David S. Miller <davem@davemloft.net> 1439837425 -0700

Merge branch 'iff_no_queue'

Phil Sutter says:

====================
net: introduce IFF_NO_QUEUE as successor of zero tx_queue_len

This series adds a new private net_device flag indicating that a device may
(and probably should) be used without a queueing discipline attached to it.
This is already common practice for many virtual device types like e.g.
loopback, VLAN (802.1Q) or bridges (802.1D). The reason for this is that these
devices lack an underlying layer which could impose back pressure and therefore
making a TX queue necessary to not slow down senders.

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,
limiting the queue to zero packets and thus prevents any TX from happening. To
overcome this, practically all qdisc implementations intercept and sanitize the
malicious value.

With this series applied, drivers may signal the lack of need for a qdisc
without having to tamper with tx_queue_len, making fallbacks in qdiscs and
caveats in userspace unnecessary.

Upon upstream acceptance, this series will be followed up by a set of patches
converting device drivers, adding a warning so out-of-tree driver authors get
aware of this change and dropping all special handling of tx_queue_len in
net/sched/.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>