Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: "David Täht" <dave.taht@gmail.com>
To: bloat-devel@lists.bufferbloat.net,
	 "linux-wireless@vger.kernel.org"
	<linux-wireless@vger.kernel.org>
Subject: [RFC] ipv6 over wireless classification issue?
Date: Sun, 23 Oct 2011 12:23:25 +0200	[thread overview]
Message-ID: <4EA3EB1D.9060001@gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

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.

-- 
Dave Täht


[-- Attachment #2: dave_taht.vcf --]
[-- Type: text/x-vcard, Size: 204 bytes --]

begin:vcard
fn;quoted-printable:Dave T=C3=A4ht
n;quoted-printable:T=C3=A4ht;Dave
email;internet:dave.taht@gmail.com
tel;home:1-239-829-5608
tel;cell:0638645374
x-mozilla-html:FALSE
version:2.1
end:vcard


                 reply	other threads:[~2011-10-23 10:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EA3EB1D.9060001@gmail.com \
    --to=dave.taht@gmail.com \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox