[ovs-dev] [PATCH ovn 1/3] ovn: Enforce unique tags for container interfaces.

Jesse Gross jesse at nicira.com
Tue Apr 7 18:34:12 UTC 2015


On Tue, Apr 7, 2015 at 11:14 AM, Thomas Graf <tgraf at noironetworks.com> wrote:
> On 04/07/15 at 10:49am, Jesse Gross wrote:
>> On Tue, Apr 7, 2015 at 8:29 AM, Thomas Graf <tgraf at noironetworks.com> wrote:
>> > I remember this discussion. One alternative that comes to mind is to
>> > simply push a Geneve header in front of it. It would provide a lot
>> > more flexibility down the road and we could transmit additional metadata
>> > between inner and outer OVS later on.
>> >
>> > The OVN model would look the same, except that tag would be a 32 or
>> > 64bit Geneve option of known class and type.
>> >
>> > The disadvantages to this is obviously increased overhead but given
>> > that these packets never hit the wire and go straight from OVS to OVS.
>> > We could come up with a simplified protocol using a new ethernet type.
>> >
>> > eth + gva + ip + tcp
>>
>> For what it's worth, I think something like this is inevitable at some
>> point for a different reason anyways. Virtual appliances like
>> firewalls are going to want to start consuming some of the metadata
>> that is available in tunneling protocols and they are going to need a
>> way to get at it. I think it would be easy enough to map the currently
>> proposed vlan tag into the 24-bit VNI in the base header to
>> immediately get some breathing room and then have options available
>> future additional metadata in the future.
>
> Good point.
>
>> It seems like it is somewhat of a pain to introduce a non-IP based
>> version of Geneve (from an implementation standpoint, not the
>> protocol) since it will need new code paths for offloading, etc. It's
>> possible but it would be simpler if we can avoid it.
>
> Certainly not needed from the start and given GRO works properly
> we might not even care that much about the overhead in the end.
>
> BTW, any particular reason you are mentioning offloading? I was
> not expecting to ever see such a frame on an actual wire.

I just meant the software versions of offloading, not that we would
need actual hardware support for this. We'd want to make sure that
GSO, virtio, etc. support whatever we do in order to ensure that we
can efficiently communicate between the host and guest. Support for
normal Geneve is pretty good in this regard at the moment but if we
removed the IP header it would need to follow a new code path
throughout the stack.



More information about the dev mailing list