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.all...@nxp.com>
To: Joe Stringer <j...@ovn.org>
Cc: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] vxlan offload via dpif
Message-ID:
<db4pr04mb06224651ab59a6d9c5cc43d3e4...@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:j...@ovn.org]
Sent: Thursday, June 01, 2017 2:06 AM
To: Santhosh Alladi <santhosh.all...@nxp.com>
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] vxlan offload via dpif
 
On 31 May 2017 at 06:27, Santhosh Alladi <santhosh.all...@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.

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



y...@panath.cn
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to