[ovs-dev] [PATCH] VxLAN-gpe implementation

[Hannes Frederic Sowa]

On 09.06.2016 18:14, Alexander Duyck wrote:
> On Thu, Jun 9, 2016 at 3:57 AM, Hannes Frederic Sowa <hannes at redhat.com> wrote:
>> On 09.06.2016 04:33, Alexander Duyck wrote:
>>> On Wed, Jun 8, 2016 at 3:20 PM, Hannes Frederic Sowa <hannes at redhat.com> wrote:
>>>> The remaining problem regarding offloads would be, that we by default
>>>> get into the situation that without the special offloading rule the
>>>> vxlan stream will only be processed on one single core, as we tell
>>>> network cards not to hash the udp ports into rxhash, which hurts a lot
>>>> in case of vxlan, where we bias the flow identification on the source
>>>> port without offloading available.
>>>
>>> Most NICs offer the option of hashing on UDP ports.  In the case of
>>> the Intel NICs I know you can turn on UDP port hashing by using
>>> ethtool and setting UDP hasing to be enabled via "ethtool -N <iface>
>>> udp4 sdfn".  You can do the same thing using "udp6" for IPv6 based
>>> tunnels.  That is usually enough to cover all the bases and the fact
>>> is not too many people are passing fragmented UDP traffic and as long
>>> as that is the case enabling UDP hashing isn't too big of a deal.
>>
>> True, I am wondering how safe it is given the reordering effects it has
>> on UDP and thus other non vxlan management protocols on the hypervisors.
>>
>> At that time, when UDP port hashing was disabled, the message was pretty
>> clear by upstream and I don't think for the default case anything should
>> change here.
>>
>> Are the port hashing features also global or tweakable per VF?
> 
> That one depends on the device.  I think in the case of some of the
> newer NICs the VFs support separate RSS tables.  The ones that have
> shared RSS tables typically share how they compute the hashes.  So for
> example with igb and ixgbe you get a shared has computation where the
> PF will impact the VFs.  One easy fix for the reordering though is to
> simply disable RSS on the VFs which in many cases will likely occur
> anyway unless the guest has multiple VCPUs.

Sounds like a bad limitation. I assume multiple VCPUs are used in VMs (I
even do that).

Hypothetically for IPv4 vxlan in a datacenter, can't we randomize the
IPv4 address bits and isolate it properly just as the transport protocol
for vxlan (e.g. the lower 2 bytes)? But that is becoming ugly...

We break ICMP already with UDP source port randomization.

> In the case of ixgbe it just occurred to me that there is also an
> option of applying flow director rules and it would be possible to
> just add a rule for each CPU so that you split the UDP source port
> space up based on something like the lower 4 bits assuming 16 queues
> for instance.

The deployment of that based on the used hardware will also be terrible.

Bye,
Hannes