Hi, I looked into the code of truncate, I saw that patch ports are not handled. On the other hand I saw that "Avoid recirculation" commit should not be affected by this fact. I verified that packets are truncated correctly with my last patch I sent you before, but flow stats are not correct on the underlay bridge.
Could you confirm this, please? Best regards, Zoltan > -----Original Message----- > From: Zoltán Balogh > Sent: Sunday, May 07, 2017 9:16 PM > To: 'Joe Stringer' <[email protected]>; William Tu <[email protected]> > Cc: Sugesh Chandran <[email protected]>; ovs dev > <[email protected]>; Ben Pfaff <[email protected]>; Andy Zhou > <[email protected]>; Jan Scheurich <[email protected]> > Subject: RE: [ovs-dev] [PATCH v5] tunneling: Avoid recirculation on datapath > by computing the recirculate actions at > translate time. > > > >> I have a patch that fixes tunneling over patch ports. The 14th > > >> system-userspace > > >> test still does fail, but now the packet size in the dump flow remains > > >> 242. > > >> > > >> ./system-traffic.at:554: ovs-ofctl dump-flows br0 | grep "in_port=2" | > > >> sed -n 's/.*\(n\_bytes=[0-9]*\).*/\1/p' > > >> ./system-traffic.at:558: ovs-ofctl dump-flows br-underlay | grep > > >> "in_port=LOCAL" | sed -n 's/.*\(n\_bytes=[0- > > 9]*\).*/\1/p' > > >> --- - 2017-05-05 19:52:28.987111424 +0200 > > >> +++ > > >> /home/ezolbal/work/general_L3_tunneling/ovs/tests/system-userspace-testsuite.dir/at-groups/14/stdout > > 2017-05-05 19:52:28.983508027 +0200 > > >> @@ -1,2 +1,2 @@ > > >> -n_bytes=138 > > >> +n_bytes=242 > > >> > > >> I'm little bit lost with flow statistics. Could you have a look at the > > >> patch > > >> below, and help me to find out if it's only a statistics bug, please? > > > > > > Ah, so the more interesting part of that test is that it also > > > truncates the packet during output to the tunnel. So the tunnel should > > > only see a 100B packet (encapped within GRE, so 138B). Commit > > > aaca4fe0ce9e ("ofp-actions: Add truncate action.") was where this > > > functionality was originally introduced, perhaps you can look at that > > > to determine how the truncation should be applied in this case? > > > > Looking again, I think this also states that regardless of the > > truncate, the second bridge should attribute stats for the encapped > > packet, so even if there was no truncation it should be more than > > 242B. When it comes to applying geneve TLVs as well, I'd expect this > > to be calculated correctly. > > Hi Joe, > Hi William, > > I was thinking about the "Avoid recirculation" code created by Sugesh and > myself. It is based on the code patch > ports do use. > So I reverted our "Avoid recirculation" commit on master branch and tried to > truncate packets on a patch port. > I used the setup below. > > > 192.168.10.10 192.168.10.20 > ns0 ns1 > | | > | br0-ns0 | br1-ns1 > +--o-------+ +--o-------+ > | | | | > | br0 | | br1 | > | | | | > +--o----o--+ +--o----o--+ > veth0 | | patch0 patch1 | | veth1 > | +----------------+ | > | | > +--------------------------+ > > > I attached two namespaces (ns0, ns1) to two netdev bridges (br0, br1), then I > connected the bridges over veth and > patch ports. > > netdev@ovs-netdev: hit:915736 missed:28 > br0: > br0 65534/1: (tap) > br0-ns0 1/3: (system) > patch0 2/none: (patch: peer=patch1) > veth0 3/5: (system) > br1: > br1 65534/2: (tap) > br1-ns1 1/4: (system) > patch1 2/none: (patch: peer=patch0) > veth1 3/6: (system) > > When I added flow rules to forward and truncate packets over veth ports, the > ping from ns0 to ns1 did work. > > $ ovs-ofctl del-flows br0 > $ ovs-ofctl del-flows br1 > $ ovs-ofctl add-flow br0 in_port=1,action=3 > $ ovs-ofctl add-flow br0 in_port=3,actions=1 > $ ovs-ofctl add-flow br1 in_port=3,actions=1 > $ ovs-ofctl add-flow br1 in_port=1,actions=output\(port=3,max_len=200\) > > $ ip netns exec ns0 ping 192.168.10.20 > > flow-dump from non-dpdk interfaces: > recirc_id(0),in_port(3),eth_type(0x0800),ipv4(frag=no), packets:180, > bytes:17640, used:0.610s, actions:5 > recirc_id(0),in_port(5),eth_type(0x0800),ipv4(frag=no), packets:24, > bytes:2352, used:0.610s, actions:3 > recirc_id(0),in_port(4),eth_type(0x0800),ipv4(frag=no), packets:178, > bytes:17444, used:0.610s, > actions:trunc(200),6 > recirc_id(0),in_port(6),eth_type(0x0800),ipv4(frag=no), packets:25, > bytes:2450, used:0.610s, actions:4 > > When I added flow rules to forward and truncate packets over patch ports, > then ping reply packets did not arrive. > > $ ovs-ofctl del-flows br0 > $ ovs-ofctl del-flows br1 > $ ovs-ofctl add-flow br0 in_port=1,action=2 > $ ovs-ofctl add-flow br0 in_port=2,actions=1 > $ ovs-ofctl add-flow br1 in_port=2,actions=1 > $ ovs-ofctl add-flow br1 in_port=1,actions=output\(port=2,max_len=200\) > > $ ip netns exec ns0 ping 192.168.10.20 > > flow-dump from non-dpdk interfaces: > recirc_id(0),in_port(3),eth_type(0x0800),ipv4(frag=no), packets:132, > bytes:12936, used:0.122s, actions:4 > recirc_id(0),in_port(4),eth_type(0x0800),ipv4(frag=no), packets:131, > bytes:12838, used:0.121s, actions:drop > > It seems that truncate on patch ports does not work. Since our "Avoid > recirculation" code reuses the code which > handles patch ports, my assumption is that we have to solve two problems. > 1) get truncate to work on patch ports. > 2) then our "Avoid recirculation" code could reuse the working patch port > code and update flow and base_flow data > properly before tunnel header is pushed during translation. > > What do you think? > > Best regards, > Zoltan _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
