On Dec 21, 2012, at 2:00 , ext Jesse Gross wrote: > On Thu, Dec 20, 2012 at 8:08 AM, Jarno Rajahalme > <jarno.rajaha...@nsn.com> wrote: >> >> Signed-off-by: Jarno Rajahalme <jarno.rajaha...@nsn.com> >> --- >> v3 removes setting OVS_KEY_ATTR_TUN_ID in a key by itself as kernel would >> reject it anyway. Correspondingly removes odp-level test cases where tun_id >> was set alone. > > There's actually a reason for this: at this point in time, there has > been no break in compatibility between userspace and kernel. It will > have to happen eventually but I'd like to delay it as long as possible > because that makes it less likely that we'll have to change things > multiple times. > > On old kernels, this will drop the tunnel information and therefore > break compatibility.
So it would be good to keep the use of OVS_KEY_ATTR_TUN_ID in a key for now to keep older kernels happy? > >> diff --git a/tests/odp.at b/tests/odp.at >> index 43b79d6..7bb47c6 100644 >> --- a/tests/odp.at >> +++ b/tests/odp.at >> @@ -31,8 +31,8 @@ >> skb_mark(0x1234),in_port(1),eth(src=00:01:02:03:04:05,dst=10:11:12:13:14:15),eth >> cat odp-base.txt >> >> echo >> - echo '# Valid forms with tun_id header.' >> - sed 's/^/tun_id(0x7f10354),/' odp-base.txt >> + echo '# Valid forms with tunnel header.' >> + sed >> 's/^/ipv4_tunnel(tun_id=0x7f10354,src=10.10.10.10,dst=20.20.20.20,tos=0x0,ttl=64,flags(df,key)),/' >> odp-base.txt > > It doesn't really matter for the purposes of the unit tests but the df > flag is only used on transmit and these flows are all related to > receive, so this can never actually happen. OK. I actually had a bug where multiple flags would not be handled properly, so it would be nice to keep a test with multiple flags set. flags(csum,key) should be valid for key, right? It would actually be nice if we documented the semantics of the tunnel metadata flags. For example, should TNL_F_CSUM also be "transmit only", or is it necessary to split the exact matches based on the presence of a tunneling level checksum? On the same note, should VXLAN set this flag based on the presence of UDP checksum (vxlan makes verification of the UDP checksum optional, and recommends sending it as zero)? Furthermore, it seems that flow-based tunnels would always need the key, both in receive (key) and transmit (set action). If so, what use is there for OVS_TNL_F_KEY? > >> >> echo >> echo '# Valid forms with VLAN header.' >> @@ -44,14 +44,14 @@ s/$/)/' odp-base.txt >> sed 's/^/skb_priority(0x1234),/' odp-base.txt >> >> echo >> - echo '# Valid forms with tun_id and VLAN headers.' >> - sed 's/^/tun_id(0xfedcba9876543210),/ >> + echo '# Valid forms with tunnel and VLAN headers.' >> + sed >> 's/^/ipv4_tunnel(tun_id=0x7f10354,src=10.10.10.10,dst=20.20.20.20,tos=0x0,ttl=64,flags(key)),/ > > I think before I had some different variations on the flow for each > test (such as longer keys, different values, etc.). It would be nice > to keep that since it tests out a few more combinations. OK. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
