On 30/06/16 20:23, Kevin Darbyshire-Bryant wrote:
On 30/06/16 11:27, Jonathan Morton wrote:
On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant
<[email protected]> wrote:
+#ifdef CONFIG_NET_SCH_ESFQ_NFCT
+ enum ip_conntrack_info ctinfo;
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
+#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.
I knew I shouldn't have got so excited. It sort of half works-ish. I
hacked something together and then added a few printk statements to
help with debugging. For testing I setup 'dual-dst' on the ifb4wan
(ingress) interface, and set 'dual-src' on the wan4 (egress)
interface. Testing showed the input side of things hadn't got as far
as conntrack association by the time it hit the qdisc. The output
side of things definitely has conntrack associations. They're a bit
strange and I need to do a bit more digging to see if there's anything
useful here, it might be possible to do per host egress fairness.
For reasons I don't understand it looks as though I'm occasionally
seeing the 'reply' conntrack association and not just the
'incoming'...in other words I'm seeing 'internet' source addresses,
not just internal lan.
I'm beginning to think there's a reason why enhanced sfq which is
where I found that code never made it upstream :-/ It's been/being
an interesting little diversion...and I've modified a kernel module
that so far doesn't crash :-)
KDB
The brain cell awoke with the thought that 'we don't need all the
conntrack info filled in, all we need is to find the conntrack entry
matching the src/dst tuple depending on direction. nf_ct_get(skb,
&ctinfo) is a function of convenience....we need to do it the
inconvenient way. there's gotta be conntrack tuple lookups available
and we must have enough info for this as the skb is right there. KDB
goes digging.
KDB
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
