On Thu, Jul 04, 2019 at 05:28:19PM +0300, Paul Blakey wrote: > Hi, > > The following patches add connection tracking offload to tc. > > We plan on offloading the datapath rules to netdev one to one to tc rules. > We'll be using upcoming act_ct tc module which is currently under review in > netdev for the datapath ct() action. > Tc chains and tc goto chain action for the recirc_id() match and recirc() > action. > cls_flower will do the matching on skb conntrack metadata for the ct_state > matches. > > The patchset for act_ct and cls_flower is here: > https://lwn.net/Articles/791584/ > > So datapath ovs connection tracking rules: > recirc_id(0),in_port(ens1f0_0),ct_state(-trk),... actions:ct(zone=2),recirc(2) > recirc_id(2),in_port(ens1f0_0),ct_state(+new+trk),ct_mark(0xbb),... > actions:ct(commit,zone=2,nat(src=5.5.5.7),mark=0xbb),ens1f0_1 > recirc_id(2),in_port(ens1f0_0),ct_state(+est+trk),ct_mark(0xbb),... > actions:ct(zone=2,nat),ens1f0_1 > > recirc_id(1),in_port(ens1f0_1),ct_state(-trk),... actions:ct(zone=2),recirc(1) > recirc_id(1),in_port(ens1f0_1),ct_state(+est+trk),... > actions:ct(zone=2,nat),ens1f0_0
Hi Paul, Sometimes I'm seeing ghosts^Wbogus values with nat: [root@localhost ~]# ovs-ofctl dump-flows br0 cookie=0x0, duration=788.595s, table=0, n_packets=3, n_bytes=180, priority=50,ct_state=-trk,tcp,in_port="ns2-veth-ab" actions=ct(table=0,zone=2) cookie=0x0, duration=788.584s, table=0, n_packets=0, n_bytes=0, priority=50,ct_state=-trk,tcp,in_port="ns1-veth-ab" actions=ct(table=0,zone=2) cookie=0x0, duration=788.589s, table=0, n_packets=3, n_bytes=180, priority=50,ct_state=+new+trk,tcp,in_port="ns2-veth-ab" actions=ct(commit,zone=2,nat(src=192.168.0.30)),output:"ns1-veth-ab" cookie=0x0, duration=788.551s, table=0, n_packets=0, n_bytes=0, priority=50,ct_state=+est+trk,tcp,in_port="ns1-veth-ab" actions=ct(zone=2,nat),output:"ns2-veth-ab" cookie=0x0, duration=788.546s, table=0, n_packets=0, n_bytes=0, priority=50,ct_state=+est+trk,tcp,in_port="ns2-veth-ab" actions=ct(zone=2,nat),output:"ns1-veth-ab" cookie=0x0, duration=788.531s, table=0, n_packets=22, n_bytes=1672, priority=10 actions=NORMAL [root@localhost ~]# cat /proc/net/nf_conntrack ipv4 2 tcp 6 26 SYN_SENT src=192.168.0.2 dst=192.168.0.1 sport=41524 dport=5001 [UNREPLIED] src=192.168.0.1 dst=233.185.30.138 sport=5001 dport=41524 mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=2 use=2 Note the 'dst=233.185.30.138' where it should have been 192.168.0.30. Interesting that it is always this address. Here, it worked: ipv4 2 tcp 6 58 CLOSE_WAIT src=192.168.0.2 dst=192.168.0.1 sport=41616 dport=5001 src=192.168.0.1 dst=192.168.0.30 sport=5001 dport=41616 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=2 use=2 I cannot reproduce this with direct tc tests and neither with hw_offload=false. I'm using: kernel: 192f0f8e9db7efe4ac98d47f5fa4334e43c1204d + recird_id patches iproute2: 0f48f9f46ae83c042d36c1208b0f79966f92a951 + act_ct patches ovs: c99d14775f78cb38b2109add063f58201ba07652 + this series (including the fixup) _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
