[ovs-discuss] [OVS v2.4.0] - VXLAN UDP port configuration is not notified to L2 driver/interface.
jesse at nicira.com
Thu Sep 10 14:43:14 UTC 2015
On Thu, Sep 10, 2015 at 12:23 AM, Manish Chopra
<manish.chopra at qlogic.com> wrote:
>> -----Original Message-----
>> From: Jesse Gross [mailto:jesse at nicira.com]
>> Sent: Thursday, September 10, 2015 2:09 AM
>> To: Manish Chopra; Thomas Graf
>> Cc: bugs at openvswitch.org; pshelar at nicira.com; Yuval Mintz; Ashish Kumar
>> Subject: Re: [OVS v2.4.0] - VXLAN UDP port configuration is not notified to L2
>> On Wed, Sep 9, 2015 at 1:06 PM, Manish Chopra <manish.chopra at qlogic.com>
>> >> -----Original Message-----
>> >> From: Jesse Gross [mailto:jesse at nicira.com]
>> >> Sent: Wednesday, September 09, 2015 10:41 PM
>> >> To: Manish Chopra
>> >> Cc: bugs at openvswitch.org; pshelar at nicira.com; Yuval Mintz; Ashish
>> >> Kumar
>> >> Subject: Re: [OVS v2.4.0] - VXLAN UDP port configuration is not
>> >> notified to L2 driver/interface.
>> >> On Wed, Sep 9, 2015 at 3:03 AM, Manish Chopra
>> >> <manish.chopra at qlogic.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Detailed Description :
>> >> >
>> >> > I am trying to test VXLAN with OVS bridge with L2 driver. With OVS
>> >> > release version [2.4.0] package VXLAN udp port configuration is not
>> >> > notified to L2 driver
>> >> >
>> >> > via ndo_add_vxlan_port interface. Due to this hardware is not able
>> >> > to do offload of features [like checksum etc.], Hence TCP/IP
>> >> > traffic with encapsulated offload enabled on NIC is not working.
>> >> You mean offloads aren't being performed and therefore things are
>> >> slower than if it was done in hardware or traffic doesn't flow?
>> >> Offloads should never be mandatory.
>> >> What is the base kernel version?
>> > Traffic doesn't flow at all. Our hardware is supportive for encap offloads only
>> when UDP port is configured on hardware.
>> > We claim to support below features for encapsulation -
>> > ndev->hw_enc_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM
>> I believe that the correctness issue is actually in the driver. You can't assume
>> that encapsulation means VXLAN or that the port will be registered. There are
>> other protocols that set this and there are also other sources for offloaded
>> encapsulation packets, such as VMs. You're going to have to do some filtering of
>> offloads in ndo_features_check to support this hardware.
>> That being said, there is a performance regression in OVS. Thomas, I believe that
>> this is a result of the GBP changes since that caused kernels that previously
>> supported receive offloads and GRO to use the compat code, which doesn't
>> support them. Would you mind taking a look?
> I didn't get it much. What would have caused performance regression due to notifying UDP port ?
> Not sure how it is doable the said filtering ? "ndev->hw_enc_features" is the mask of the features inherited by encapsulating device, it could be geneve/gre on top of
> base device. Given that VXLAN udp port is not notified we can't just remove these features from " ndev->hw_enc_features" as it might affect other encap device features.
What I mean is that I agree that OVS is not notifying drivers about
VXLAN ports in 2.4 on certain kernels. However, I consider that to be
a performance regression due to the loss of receive side offloads,
such as checksum. The fact that traffic is not flowing I believe is an
issue with the driver.
Here's an example: You mentioned Geneve, which is also a UDP-based
encapsulation but does not currently have support for registering the
receive UDP port, thereby making the netdevice very similar to VXLAN
in OVS 2.4. If you send Geneve traffic with offloads, will the packets
get dropped? My guess is yes.
Assuming that is true, I see three possible solutions in your driver:
* Ideally, find a way to decouple transmit and receive offload.
* Continue advertising transmit offloads but for those that can't be
supported, dynamically remove their offloads using
ndo_features_check() (See the Intel fm10k driver for an example of
* Don't advertise encapsulation offloads.
More information about the discuss