On Wed, 2006-11-01 at 01:54 -0800, Amnon Aaronsohn wrote: > > > So it is an optimization - not a bug then, > > correct? > > It's a bug fix that happens to be an optimization :) > > > > No matter what you set skb->priority to, that gets > > translated > > by prio2band[] which should only point to actually > > initialized > > queues. > > That's not correct. If prio_classify() sees that > TC_H_MAJ(skb->priority) equals the qdisc's handle, it > uses > TC_H_MIN(skb->priority)-1 as the band number. No > prio2band[] > involved.
Are you are refering to this code? u32 band = skb->priority; ... ... band = TC_H_MIN(band) - 1; if (band > q->bands) return q->queues[q->prio2band[0]]; return q->queues[band]; You will always point to correctly initialized queues with any value of skb->priority. That doesnt mean your code should be setting it to some outrageous value - that would be a bug on your part. > That's how the CLASSIFY iptables target (for > example) can set the band number. > > I take that to be a feature of PRIO -- that you can > set the band directly. > yes, but where is the bug? > > If your netfilter module is accessing the PRIO qdisc > > data > > structures directly, you're not really supposed to > > do that. > > I'm only setting skb->priority. It can even be done > (indirectly) from user space using setsockopt() > SO_PRIORITY option. > not just that, it can also be derived from a packet being forwarded, vlan 8012p outbound etc; but thats besides the point. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html