Re: [Cake] flow dissector idea/enhancement - help

[Jonathan Morton]

> On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant 
>  wrote:
> 
> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT
> +   enum ip_conntrack_info ctinfo;
> +   struct nf_conn *ct = nf_ct_get(skb, );
> +#endif

Good find.  If this actually works the way we want it to, it’ll make all the 
host-dependent modes (including triple-isolation) much more useful on the outer 
side of a NAT.

My main concern is that the conntrack state might not be sorted out until it 
hits the firewall or routing logic.  I’ll be very pleased if it happens sooner, 
or is actually triggered by the query rather than passing to some specific 
stage of processing.

I have other work to do on the host and flow processing, but I think that’ll be 
independent of the hash function, which is where you want to be looking.

 - Jonathan Morton

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] flow dissector idea/enhancement - help

[Kevin Darbyshire-Bryant]

On 02/06/16 13:29, Jonathan Morton wrote:

On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant 
 wrote:

Cake uses the flow dissector API to do flow hashing...including per host flows 
for dual/triple isolation.  The unfortunate bit is that the qdisc inevitably 
gets placed after packets have been NATed on egress and before they've been 
de-NATed on ingress.

When mentioned before Johnathan said "flow dissector ideally needs to be tweaked to 
do this" or words to that effect.

I'd like to progress that idea...the thought of me kernel programming should 
horrify everyone but really I'm asking for help in being pointed in the right 
direction to ask for help...and go from there :-)

I believe Linux does NAT using a “connection tracker” subsystem.  That would 
contain the necessary data for resolving NAT equivalents.  I don’t know how 
easy it is to query in a qdisc context, though.
Imagine my joy of discovering http://fatooh.org/esfq-2.6/  - someone has 
already bl**dy done itand I found it lurking in LEDE as part of a patch.


So there relevant bits are something of the order:


+#ifdef CONFIG_NET_SCH_ESFQ_NFCT
+   enum ip_conntrack_info ctinfo;
+   struct nf_conn *ct = nf_ct_get(skb, );
+#endif

+#ifdef CONFIG_NET_SCH_ESFQ_NFCT
+   /* defaults if there is no conntrack info */
+   info.ctorigsrc = info.src;
+   info.ctorigdst = info.dst;
+   info.ctreplsrc = info.dst;
+   info.ctrepldst = info.src;
+   /* collect conntrack info */
+   if (ct && ct != _conntrack_untracked) {
+   if (skb->protocol == __constant_htons(ETH_P_IP)) {
+   info.ctorigsrc = 
ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip;
+   info.ctorigdst = 
ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip;
+   info.ctreplsrc = 
ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip;
+   info.ctrepldst = 
ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip;

+   }
+   else if (skb->protocol == __constant_htons(ETH_P_IPV6)) {
+   /* Again, hash ipv6 addresses into a single u32. */
+   info.ctorigsrc = 
jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip6, 4, 
q->perturbation);
+   info.ctorigdst = 
jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip6, 4, 
q->perturbation);
+   info.ctreplsrc = 
jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip6, 4, q->perturbation);
+   info.ctrepldst = 
jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip6, 4, q->perturbation);

+   }
+
+   }
+#endif

I'd rip out the IPv6 conntrack stuff as I'm much more concerned by 
handling IPv4 NAT.  And I'm not sure how to get it into cake's host 
handling yet but


I can feel an experiment and hackery coming on later today :-)

Am overjoyed!
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Codel] Proposing COBALT

[Kevin Darbyshire-Bryant]

On 29/06/16 16:22, Kevin Darbyshire-Bryant wrote:



Ok, so the above is done: cobalt merged into mainline cake/master. 
cobalt branch rebased/fast-forwarded to the same place, so don't 
forget to 'git pull' (or fetch & merge) your own repos.


Patches for LEDE to point at those latest updates have been sent in 
and subject to build testing should be accepted shortly.

Now accepted.


The updated tc containing package will be 'tc_4.4.0-3' - note the 
version 3.


I'm still trying to understand why the kmod-sched-cake package version 
doesn't change in quite the way I expected ;-)
Solved that too - some 'legacy' package makefile cruft.   You're looking 
for kmod-sched-cake - 
4.4.14+2016-06-29-747954dd0bde66bb28d2b6c2c109597c9abbe5c5-1 in the 
output of 'opkg list' as the COBALT enabled version of cake.


Kevin

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake