[ovs-dev] [PATCH v3] Add ODP level handling of OVS_KEY_ATTR_IPV4_TUNNEL.

Jarno Rajahalme jarno.rajahalme at nsn.com
Fri Dec 21 08:04:29 UTC 2012


On Dec 21, 2012, at 2:00 , ext Jesse Gross wrote:
> On Thu, Dec 20, 2012 at 8:08 AM, Jarno Rajahalme
> <jarno.rajahalme at nsn.com> wrote:
>> 
>> Signed-off-by: Jarno Rajahalme <jarno.rajahalme at 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.




More information about the dev mailing list