netdev - Re: Is there a preferred way to get the VXLAN port number?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51533B5B.9030405@intel.com>
Date:	Wed, 27 Mar 2013 11:32:59 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Jesse Gross <jesse@...ira.com>
CC:	netdev <netdev@...r.kernel.org>,
	"Gasparakis, Joseph" <joseph.gasparakis@...el.com>,
	Stephen Hemminger <shemminger@...tta.com>, pshelar@...ira.com,
	David Miller <davem@...emloft.net>
Subject: Re: Is there a preferred way to get the VXLAN port number?

On 03/27/2013 10:26 AM, Jesse Gross wrote:
> On Tue, Mar 26, 2013 at 3:02 PM, Alexander Duyck
> <alexander.h.duyck@...el.com> wrote:
>> I was wondering if someone would happen to know if there is already a
>> preferred way to get the VXLAN port number for things such as
>> configuring a device to recognize a VXLAN frame on receive for parsing
>> purposes?
>>
>> I just wanted to check to make sure I hadn't missed something before
>> submitting a patch that would export a simple function for supplying the
>> vxlan_port value.
> There isn't a good way to do this at the moment.  One thing that would
> be nice though is if we can make this as generic as possible to
> different tunneling formats that might need to be configured in this
> way rather than specific to VXLAN.
>
> Another area think about is how best to supply the information to
> GRO/RPS to do the software version of these offloads.

The problem is what I am looking for is very specific to VXLAN.  I need
the port number so I can tell the hardware where to expect the VXLAN
frames to be bound to so that the hardware will recognize them and parse
them correctly.

In the case of GRO/RPS the situation is somewhat reversed.  You have a
packet with a given port number and you need to offload it.  In that
case you can probably do a socket search to determine which offload to
use and have those offloads associated with the socket via something
like the encap_rcv pointer that exists in the udp socket.

The main think I want to do is keep this simple since I would prefer to
not build up any infrastructure that will just get in the way.  My
thought for now is to just export a function to allow drivers to fetch
the port number of VXLAN.  The only downside is that it forces the VXLAN
module to load if a driver comes up with offload support, similar to how
we have been loading the 8021q module for many of the drivers that
support VLAN offloads.  Hopefully if the fixed port number approach wins
out we can simplify things by replacing the function call with a static
define. 

Thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html