On Fri, Dec 21, 2012 at 3:04 AM, Jarno Rajahalme <jarno.rajaha...@nsn.com> wrote: > 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?
Yes, for the time being. Once all of the userspace components switch over to using flow based tunneling then we can drop support for OVS_KEY_ATTR_TUN_ID and that will be our transition point. >> >>> 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? Yes, that's valid. > 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? It would be great if you want to document these flags. To answer your questions: * CSUM and KEY can be used on both transmit and receive. * I think CSUM could be used in the manner that you are describing for VXLAN although we don't currently support computation on transmit or verification on receive so it's not used now. I think we're following the best practices from the draft so I don't know that we want to make any changes here. * An example of the use of KEY is with GRE which has a variable length header and the key can be completely not present, so that flag distinguishes from a zero key. Other protocols, like VXLAN, don't have this distinction. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
