From: Patrick McHardy <kaber@trash.net>
Date: Thu, 17 Jul 2008 16:02:20 +0200

quoted text
> 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 netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html