From: Patrick McHardy <kaber@xxxxxxxxx> Date: Thu, 17 Jul 2008 16:02:20 +0200 > jamal wrote: > > On Thu, 2008-17-07 at 15:03 +0200, Patrick McHardy wrote: > > > > Like you i need to digest the patches to understand the impact on the > > rest but one thing i did notice was the last patch (replacement of > > pfifo_fast): > > 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. -- 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
