From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3164621F778 for ; Thu, 10 Dec 2015 04:49:14 -0800 (PST) Received: by qgeb1 with SMTP id b1so140205570qge.1 for ; Thu, 10 Dec 2015 04:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FS621KW58+oyp0Wz6IDYMqiW8IR3+doLlCqF6YRu8Pk=; b=0Os1smfqfgWj1UaDG9wZ3md6q6F0AElEhh16CyzKd6R+PmnlUM272cjXWNcGVSjZMx eXJ0NTqGUjQK4TFekISiwPCaMg5ftvsCFWcPt8/C52r6mpjdUpMMHfan51UGGSZKiGs4 CBqNnNHMmMbDwFx+sgfAIeDLtEKpWQdZJBnXgzEyx6J0oPh1Hx7qBDcWQl+H+Z8tFNi9 Ou9DXUgEKwMCTWn+RfAq8Tiyu3Qfo5rh7IAYRslwAwxdUSpOAA80ysSMCts95I6EP3Vz Q1qqXdpGQCMCSthbBOhPnP09YkhTvIoVbmrf5cgvWxZ62UL+X/ZwF1iT3uT6gwvATzQC b4bA== MIME-Version: 1.0 X-Received: by 10.129.147.194 with SMTP id k185mr4364896ywg.284.1449751753746; Thu, 10 Dec 2015 04:49:13 -0800 (PST) Received: by 10.37.112.6 with HTTP; Thu, 10 Dec 2015 04:49:13 -0800 (PST) In-Reply-To: <5669737C.8070503@darbyshire-bryant.me.uk> References: <5664173D.40808@darbyshire-bryant.me.uk> <56695F78.5020802@darbyshire-bryant.me.uk> <56696B65.4040608@darbyshire-bryant.me.uk> <5669719D.9030609@darbyshire-bryant.me.uk> <5669737C.8070503@darbyshire-bryant.me.uk> Date: Thu, 10 Dec 2015 13:49:13 +0100 Message-ID: From: Dave Taht To: Kevin Darbyshire-Bryant Content-Type: text/plain; charset=UTF-8 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] dscp & tunneling X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 12:49:37 -0000 etags (or ctags) are friends here, as is cscope. I am in deep gratitude to toke for supplying me a pretty good working .emacs.d set of files for browsing code recently - I'd lost 20 years worth of accumulated tools when my lab got stolen and don't do enough software development today to justify sinking the time into making emacs sing and dance anymore. That said, I don't understand 90% of all the cool stuff he handed me... in the linux kernel tree, do a make TAGS. then in emacs it's esc->. to look up a symbol. There are ton of other things in cscope that are pretty amazing. vi has similar interfaces as do eclipse. On Thu, Dec 10, 2015 at 1:43 PM, Kevin Darbyshire-Bryant wrote: > > > On 10/12/15 12:35, Kevin Darbyshire-Bryant wrote: >> >> On 10/12/15 12:22, Dave Taht wrote: >>> On Thu, Dec 10, 2015 at 1:09 PM, Kevin Darbyshire-Bryant >>> wrote: >>> >>>> the same test shows all those flows going in the best effort tin and >>>> nothing being split out according to dscp. Things are split out >>>> correctly with ipv4. Assuming that my installation of flent is doing >>>> the right thing (putting dscp on its outbound ipv6 packets) and knowing >>>> that both flent & cake handle the ipv4 version of the test correctly and >>>> that by the time 'cake' sees my tunnel it's all ipv4 outer packets >>>> anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking >>>> place, at least for 6in4 'sit' tunnels :-( >>> Wireshark is your friend here. >> I shall befriend it once again :-) >>> It would not surprise me if dscp inherit had broken again, or, it was >>> borked on decapsulation. Not a widely tested feature, that. >> I'm only 'testing' the encapsulation side...ipv6 into router, router >> encapsulates into ipv6, cake then sits across 'eth0' the Internet facing >> interface and isn't classifying the flows - and I swear this used to work. I had it working 3 years back, yes, also. >>> I remember making it work several years ago, remember sort of seeing >>> the patches go upstream somewhere.... it was a long time ago. >> Is there anyone lurking on this list, with the time, who can help me >> with net/ipv6/sit.c? >> >> It looks like this is the relevant area: Need to see what >> INET_ECN_encapsulate does (and where tos gets set) >> >> if (ttl == 0) >> ttl = iph6->hop_limit; >> tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6)); >> >> if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0) { >> ip_rt_put(rt); >> goto tx_error; >> } >> >> skb_set_inner_ipproto(skb, IPPROTO_IPV6); >> >> err = iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, >> protocol, tos, ttl, df, >> !net_eq(tunnel->net, dev_net(dev))); >> iptunnel_xmit_stats(err, &dev->stats, dev->tstats); >> return NETDEV_TX_OK; > Ahhh....further up... > > if (tos == 1) > tos = ipv6_get_dsfield(iph6); > > and further up still... > > static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb, > struct net_device *dev) > { > struct ip_tunnel *tunnel = netdev_priv(dev); > const struct iphdr *tiph = &tunnel->parms.iph; > const struct ipv6hdr *iph6 = ipv6_hdr(skb); > u8 tos = tunnel->parms.iph.tos; > > > So how & who sets (or should be setting) iph.tos = 1? > > Rabbit hole, rabbit hole...... > > > > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake >