From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Duyck Subject: Re: [net-next 02/10] udp: Expand UDP tunnel common APIs Date: Tue, 22 Jul 2014 15:55:57 -0700 Message-ID: <53CEEBFD.9020402@intel.com> References: <1406024393-6778-1-git-send-email-azhou@nicira.com> <1406024393-6778-3-git-send-email-azhou@nicira.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Andy Zhou , David Miller , Linux Netdev List To: Tom Herbert , Jesse Gross Return-path: Received: from mga02.intel.com ([134.134.136.20]:43653 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932269AbaGVW4H (ORCPT ); Tue, 22 Jul 2014 18:56:07 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 07/22/2014 03:38 PM, Tom Herbert wrote: > On Tue, Jul 22, 2014 at 2:56 PM, Jesse Gross wrote: >> On Tue, Jul 22, 2014 at 5:16 PM, Tom Herbert wrote: >>> On Tue, Jul 22, 2014 at 2:02 PM, Andy Zhou wrote: >>>> On Tue, Jul 22, 2014 at 12:52 PM, Tom Herbert wrote: >>>>>> --- a/include/net/udp_tunnel.h >>>>>> +++ b/include/net/udp_tunnel.h >>>>>> @@ -1,7 +1,10 @@ >>>>>> #ifndef __NET_UDP_TUNNEL_H >>>>>> #define __NET_UDP_TUNNEL_H >>>>>> >>>>>> -#define UDP_TUNNEL_TYPE_VXLAN 0x01 >>>>>> +#include >>>>>> + >>>>>> +#define UDP_TUNNEL_TYPE_VXLAN 0x01 >>>>>> +#define UDP_TUNNEL_TYPE_GENEVE 0x02 >>>>>> >>>>> Why do we need to define these? Caller should know what type of port is >>>>> being opened and provide appropriate encap_rcv. >>>> >>>> Assume udp tunnel layer needs to keep track of open ports, should it >>>> also keep track of the protocol associated with the port? >>>> >>> For what purpose? Other than for offloads and rcv_encap functions that >>> provide the service function anyway, what need is there for UDP layer >>> to know about this. More to the point, if I add a module to the kernel >>> with a new flavor of UDP tunneling, I shouldn't have to touch any core >>> code for things to work correctly. So by this line of thinking, >>> neither the terms VXLAN nor GENEVE should appear in any common code. >> >> The hardware will need to know what the header format is so that it >> can parse the packets on receive. And since the NIC can't exactly call >> into a function pointer like GRO can, I'm not sure that there is a >> solution that doesn't involve an identifier that needs to be listed >> somewhere. This is a pretty minimal impact - it doesn't actually >> appear in the core code. > > The hardware doesn't *need* to know this, it's must be optional and > should have no bearing on the software stack. Suggest to put them in > their own header file. Also, as HW features these should appear in > NETIF_F_* list so that we can control on a per device level rather to > enable this feature (something like how NETIF_F_GSO_* was done). > > What about support for L2TP/UDP? The hardware needs some means of knowing what UDP port numbers are used for VXLAN and/or GENEVE as the two formats contain subtle differences that we have to be ready for on the Rx path as we have to parse out the frames. We already have feature flags controlling the offloads, what the port numbers provide is a means for us to determine what Rx packets we should parse as tunnels vs standard UDP and which tunnel type we should parse it as. Thanks, Alex