[ovs-dev] [PATCH 1/1] Add support for tun_key to OVS datapath

[Kyle Mestery (kmestery)]

On Aug 21, 2012, at 2:05 AM, Simon Horman wrote:

> On Mon, Aug 13, 2012 at 12:23:51PM -0400, Kyle Mestery wrote:
>> This is a first pass at providing a tun_key which can be
>> used as the basis for flow-based tunnelling. The tun_key
>> includes and replaces the tun_id in both struct ovs_skb_cb
>> and struct sw_tun_key.
>> 
>> In ovs_skb_cb tun_key is a pointer as it is envisaged that it will grow
>> when support for IPv6 to an extent that inlining the structure will result
>> in ovs_skb_cb being larger than the 48 bytes available in skb->cb.
>> 
>> As OVS does not support IPv6 as the outer transport protocol for tunnels
>> the IPv6 portions of this change, which appeared in the previous revision,
>> have been dropped in order to limit the scope and size of this patch.
>> 
>> This patch allows all existing tun_id behaviour to still work. However,
>> when the userspace code is updated to make use of the new tun_key, the
>> old behaviour will be deprecated and removed.
> 
> Hi Kyle,
> 
> I apologise for not responding earlier, I was on holidays last week.
> 
Hi Simon,

I was on holidays last week myself.

> I haven't manually compared this patch to the original patches that I posted
> but this patch looks good to me.
> 
Thanks for reviewing this one! I hope Jesse can look at it. The main goal here
was to take your first two patches, collapse them together, and allow for the
existing tunnel configuration to remain in place. Then we can work on the next
few patches in this series after these go up.


> I do, however, have two minor comments:
> 
> 1. There seem to be some adding and removal of otherwise unrelated blank
>   lines.
> 
> 2. Ben Pfaff recently pointed out to me that OVS (almost?) consistently
>   prefixes hexadecimal strings with "0x". I notice some instances of
>   ...%"PRI... in your patch (which may well have been my work). It
>   may be worth considering using ...0x%"PRI... instead, though I am
>   unsure which is best in the context of the changes in question.

I will rework these tomorrow and resend with these changes.

Thanks!
Kyle