[LARTC] Question about tc class in skb

[LARTC] Question about tc class in skb

[Ron Dippold]

We're using tc to classify all packets currently - it avoids conflicting 
with other packages that want to play with the ipfilters, and up to this 
point has done everything we need. However now I'd like to map the four 
htb flows I've set up (and are working great on their own) to the four 
wireless hardware driver queues when the driver currently only has 
support for classifying by vlan tag or by ToS/DSCP bits.

What I'd really like to do (by modifying the driver) is just use the tc 
class id to map directly to the hardware queue, since we've already 
classified them correctly. However by the time it gets into the driver 
nothing in the skb seems to be usefully set to allow this.

I'm looking at skb->priority, skb->dst->tclassid, skb->tc_classid, 
skb->tc_index, skb->tc_verd (okay, that was reaching). If I ping with 
different QoS bits which I'm assigning to different htb flows, I see 
(these are my debugging messages in the driver):

~$ ping -Q 0x10 172.29.50.230
kernel: outpkt: priority:06 tclassid:0x0 tc_classid:0x0 tc_index:0x0 
tc_verd:0x2000 nfmark:00

~$ ping -Q 0x08 172.29.50.230
kernel: outpkt: priority:02 tclassid:0x0 tc_classid:0x0 tc_index:0x0 
tc_verd:0x2000 nfmark:00

Nada. 'pri' does change, but it seems to get set by the QoS value 
directly (?), no change if I map them to different flows anyhow.

Now if I use iptables and use the classify or fwmark them in POSTROUTING 
then those come through:

~$ iptables -A POSTROUTING -t mangle -m tos --tos 0x10 -j CLASSIFY 
--set-class 1:30
~$ ping -Q 0x10 172.29.50.230
kernel: outpkt: priority:65584 tclassid:0x0 tc_classid:0x0 tc_index:0x0 
tc_verd:0x2000 nfmark:00

Priority is 0x10030 hex, which I can work with. fwmark works too.


So it looks like I have three choices here.

a) maybe you can tell me something obvious I'm missing about how to get 
the real tc classid when I only have the struct sk_buff to work with and 
only tc classification was done. Am I missing a kernel option or just 
out of luck?

b) mangle the tos bits based on what flow it goes into so the driver 
will match them correctly - I'd really like to avoid that.

c) or otherwise I guess I switch all our tc rules to iproute. Oh well.

Thanks,

Ron

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc