[ovs-discuss] ovs offload

[ych at panath.cn]

hi, santhosh

   I'm glad to see that, I have had this problem recently.
   How do you deal with this? ovs full offload or ovs dataplane offload?

   Anybody have any experience with ovs offload?
========================================================================================================
Message: 3
Date: Thu, 1 Jun 2017 08:19:43 +0000
From: Santhosh Alladi <santhosh.alladi at nxp.com>
To: Joe Stringer <joe at ovn.org>
Cc: "ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>
Subject: Re: [ovs-discuss] vxlan offload via dpif
Message-ID:
<DB4PR04MB06224651AB59A6D9C5CC43D3E4F60 at DB4PR04MB0622.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
 
Hi Joe,
 
Thank you for your reply.
In our solution, we are not using the linux vxlan driver, rather we are having our own vxlan driver in our accelerator. So, for an accelerator which is connected via dpif, how can we get the tunnel information for decapsulating the packets?
 
Also, can you brief me how will the vxlan device get the tunnel information to decap the packet if the COLLECT_METADATA mode is enabled?
 
Regards,
Santhosh
 
-----Original Message-----
From: Joe Stringer [mailto:joe at ovn.org]
Sent: Thursday, June 01, 2017 2:06 AM
To: Santhosh Alladi <santhosh.alladi at nxp.com>
Cc: ovs-discuss at openvswitch.org
Subject: Re: [ovs-discuss] vxlan offload via dpif
 
On 31 May 2017 at 06:27, Santhosh Alladi <santhosh.alladi at nxp.com> wrote:
> Hi all,
>
>
>
> We are trying to configure our hardware accelerator using ovs via
> dpif. We could achieve L2 forwarding using this setup.
>
> Now, we are trying to offload complete functionality of vxlan. In this
> sense, how does vxlan processing take place in ovs-kernel. How can we
> get the tunnel information to our hardware via dpif?
 
The Linux kernel provides flow-based tunneling by attaching "metadata_dst" to the packet.
 
For instance, when OVS kernel module wants to send a packet out a vxlan device, it attaches the metadata_dst to the skbuff and transmits on the vxlan device. The Linux stack then takes over in terms of encapsulating the packet with the provided metadata and performing a route lookup to determine the next (underlay) hop for the packet.
 
On receive side, the vxlan device must be set up in COLLECT_METADATA mode and this sets up a receiver on the UDP socket which can receive the packet, decap, and attach the tunnel metadata as a metadata_dst before calling the device receive path. Then the packet is received in a similar way to any OVS-attached device, but OVS will check whether metadata_dst is set prior to performing flow table lookup. If there is metadata_dst, this needs to be received into the flow key.

========================================================================================================



ych at panath.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170619/8abbe974/attachment.html>