Bug #290

Description

After slowly working my way down from verifying the apps to ECN handling
and up from the drivers… I’ve been (also) slowly working on getting
wireless qos/aqms to work better, on ipv6. (I need to get to having a
spectrum analyzer or better instrumentation…) I was puzzled about dscp
marked ipv6 packets responding differently.

Perhaps this is it. I’m not making this a commit yet (untested code!)

d@cruithne:~/git/linux-2.6/include\$ git diff
diff –git a/net/wireless/util.c b/net/wireless/util.c
index be75a3a..a11c5f2 100644
— a/net/wireless/util.c
**+ b/net/wireless/util.c
@ -658,6 +658,12@ unsigned int cfg80211_classify8021d(struct sk_buff
*skb)
case htons(ETH_P_IP):
dscp = ip_hdr(skb)->tos& 0xfc;
break;
+ case htons(ETH_P_IPV6):
+ dscp = ipv6_get_dsfield(ipv6_hdr(skb))& 0xfc;
+ break;
+ case htons(ETH_P_ARP):
+ dscp = 4<<5;
+ break;
default:
return 0;
}

A) Elsewhere in the stack ipv4_get_dsfield is the equivalent of the
ip_hdr(skb)->tos& 0xfc line
B) It appears ipv6_get_dsfield is safe to call from non-ipv6 enabled
systems

So my thought would be to also harmonize this with ipv4_get_dsfield…

C) And I doubt that slamming arp packets into the VI queue would be
acceptable yet (as per the ANTs discussion of a few months back, ARP,
ND, RA, RS, DHCP, and possibly DNS, ssh (marked interactive), etc might
do better in the VI queue)
(however this part of the patch is not relevant to the IPv6 issue, it’s
just the patch I wanted to try)

D) Lastly, Later on in this function only dscp’s first 3 bits (CS0 -
CS7) are used to classify packets into the queues, where a mildly saner
version would use a lookup table to also do sane things with the
‘immediate’ bit, perhaps settable via userspace from via sysfs, sysctl,
or proc.

Attachments

• dave_taht.vcf (text/x-vcard; 214 bytes) David Taht Oct 23, 2011