David Miller wrote:
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Thu, 17 Jul 2008 16:02:20 +0200
jamal wrote:
prioritization based on TOS/DSCP (setsockopt) would no longer work, some
user space code may suffer (routing daemons likely). One suggestion to
fix it is to load pfifo qdisc (which does what fifo_fast is attempting)
for drivers that are h/ware multiq capable.
That would perform priorization within each qdisc, the individual
qdiscs would still be transmitted using seperate HW queues though.
I think from certain perspectives it frankly doesn't matter.
It's not like the skb->priority field lets the SKB bypass the packets
already in the TX ring of the chip with a lower priority.
It is true that, once the TX ring is full, the skb->priority thus
begins to have an influence on which packets are moved from the
qdisc to the TX ring of the device.
However, I wonder if we're so sure that we want to give normal users
that kind of powers. Let's say for example that you set the highest
priority possible in the TOS socket option, and you do this for a ton
of UDP sockets, and you just blast packets out as fast as possible.
This backlogs the device TX ring, and if done effectively enough could
keep other sockets blocked out of the device completely.
Are we really really sure it's OK to let users do this? :)
To me, as a default, I think TOS and DSCP really means just on-wire
priority.
If we absolutely want to, we can keep the old pfifo_fast around and use
it (shared on multiq) if a certain sysctl knob is set.
No, I fully agree that this is too much detail :) Its highly
unlikely that this default behaviour is important on a per
packet level :) I just meant to point out that using a pfifo
is not going to be the same behaviour as previously.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
