David Miller <davem@xxxxxxxxxxxxx> writes: > From: Toke Høiland-Jørgensen <toke@xxxxxxx> > Date: Wed, 23 May 2018 23:05:16 +0200 > >> Ah, right, that could work. Is there any particular field in sk_buff >> we should stomp on for this purpose, or would you prefer a new one? >> Looking through it, the only obvious one that comes to mind is, well, >> skb->_nfct :) >> >> If we wanted to avoid bloating sk_buff, we could add a union with that, >> fill it in the flow dissector, and just let conntrack overwrite it if >> active; then detect which is which in Cake, and read the data we need >> from _nfct if conntrack is active, and from what the flow dissector >> stored otherwise. >> >> Is that too many hoops to jump through to avoid adding an extra field? > > Space is precious in sk_buff, so yes avoid adding new members at all > costs. > > How much info do you need exactly? We use a u32 hash (from flow_hash_from_keys()) on the source address. Ideally we'd want that; but we could get away with less if we are willing to accept more hash collisions; we just need to map the source address into a hash bucket. We currently have 1024 of those, so 10 bits would suffice if we just drop the set-associative hashing for source hosts. Or maybe 16 bits to be on the safe side? It really is a pretty straight-forward tradeoff between space and collision probability. Hmm, and we still have an issue with ingress filtering (where cake is running on an ifb interface). That runs pre-NAT in the conntrack case, and we can't do the RX trick. Here we do the lookup manually in conntrack (and this part is actually what brings in most of the dependencies). Any neat tricks up your sleeve for this case? :) -Toke -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
