[ovs-dev] [PATCH v2 1/1] netdev-vport: reject concomitant incompatible tunnels

Eelco Chaudron echaudro at redhat.com
Wed May 9 14:41:05 UTC 2018


On 13/04/18 20:02, Ben Pfaff wrote:
> On Fri, Feb 09, 2018 at 03:42:56PM +0100, Eelco Chaudron wrote:
>> This patch will make sure VXLAN tunnels with and without the group
>> based policy (GBP) option enabled can not coexist on the same
>> destination UDP port.
>>
>> In theory, VXLAN tunnel with and without GBP enables can be
>> multiplexed on the same UDP port as long as different VNI's are
>> used. However currently OVS does not support this, hence this patch to
>> check for this condition.
>>
>> v1->v2
>>    Updated commit message as its now clear that the OVS  implementation
>>    does not support VNI multiplexing on the same UDP port.
>>
>> Signed-off-by: Eelco Chaudron <echaudro at redhat.com>
> Thanks for the update.
>
> Doesn't this make tunnel configuration O(n**2) in the number of tunnels?
> It looks like every tunnel checks at configuration time whether there is
> another tunnel of the same kind.  I know of some configurations with
> hundreds (thousands?) of tunnels.  Is there a way to make it cheaper?
>

Thanks for the reply, and sorry for the late response, as this was on my low
priority stack...

I looked at it again and you are right this is an expensive operation with a
lot of tunnels, especially with the smap creation.

It looks like Cascardo's original patch with a simap per port might be less
expensive. However, he forgot the cleanup and with his approach, we need to
walk all tunnels to make sure this is the last tunnel and we can remove the
simap entry. I could do a shash and keep a tunnel count to avoid the cleanup
walk. Or maybe some other way to quickly find the vport with a hmap...

I'll investigate the options a bit more and come with a v3.

Cheers,

Eelco


More information about the dev mailing list