On 6/12/2019 10:55 PM, Florian Westphal wrote: > Paul Blakey <pa...@mellanox.com> wrote: >> + /* The conntrack module expects to be working at L3. */ > It also expects that IP stack has validated ip(v6) > headers and has pulled the ip header into linear area. > > What are your plans wrt. IP fragments? AFAICS right now they will > not match which means they won't be NATed either. Is that ok?
Right, I'll add defragment via nf_ct_ipv4_gather_frags and nf_ct_frag6_gather, which is basically what conntrack_bridge and openvswitch/conntrack.c does with it's calls. > For offloading connection tracking and NAT, I think the flowtable > infrastructure is much better: it will allow any device to push packets > that it can't deal with (fragmented, too large mtu, changed route, etc) > to the software path and conntrack will be aware its dealing with a flow > that was offloaded, e.g. it will elide sequence number checks. That still be the case, Later, hardware offload for this tc rules will not offload fragmented packets (unless they somehow support it) and they will be defragmented in act_ct.c and only then will pass this action. Such offloaded connections will be marked as such and so netfilter can skip seq number checking. > For connection tracking on L2, Pablo recently added conntrack for > classic bridge (without the 'call-iptables' infrastructure), see > net/bridge/netfilter/nf_conntrack_bridge.c (especially the defrag/refrag > and header validation its doing). > > I suspect parts of that are also needed in the conntrack action (you > might be able to reuse/export some of the functionality I think).
