Is there a preferred way to get the VXLAN port number?

Is there a preferred way to get the VXLAN port number?

[Alexander Duyck]

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.

Thanks,

Alex

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

[Jesse Gross]

On Tue, Mar 26, 2013 at 3:02 PM, Alexander Duyck
<alexander.h.duyck@intel.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.

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

[Stephen Hemminger]

On Tue, 26 Mar 2013 15:02:45 -0700
Alexander Duyck <alexander.h.duyck@intel.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.
> 
> Thanks,
> 
> Alex
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

There are two views of the world. One view is that the UDP port number
should be a fixed assigned number by IANA, and since VXLAN looks exactly
like Cisco LISP, that is what most people use. Others like DOVE seem
to want to use lots of values.

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

[Alexander Duyck]

On 03/27/2013 10:26 AM, Jesse Gross wrote:
> On Tue, Mar 26, 2013 at 3:02 PM, Alexander Duyck
> <alexander.h.duyck@intel.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

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

[David Stevens]

netdev-owner@vger.kernel.org wrote on 03/27/2013 01:52:54 PM:

> On Tue, 26 Mar 2013 15:02:45 -0700
> Alexander Duyck <alexander.h.duyck@intel.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.

        To answer your question, though, the current vxlan can only listen
on one port per host, supplied with by a module parameter. You can find
what port it's listening on by:

cat /sys/modules/vxlan/parameters/udp_port

[which you can also read with a program, of course].

If multi-port server support is added, that should probably include the
port as part of the current "ip -d link show dev XXX" output, where other
per-device parameters are found.

                                                        +-DLS

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

[David Stevens]

netdev-owner@vger.kernel.org wrote on 03/27/2013 02:32:59 PM:
 
> 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. 

        I guess you mean you need to find it within the kernel.

        I think whether or not it remains a single port for the machine,
it would be just silly to make it a fixed port, period. Virtually any
service allows an administrator to specify an alternate port to run a
service on.
        I think one of the primary reasons is that you may want to run
more than one instance on the same host (e.g., a sandbox installation
alongside a production installation) -- a capability not there now,
even though you can specify an alternate port now.
        But if for whatever reason an adminstrator cares that it uses
a particular port number, even in a single instance, there is no
technical reason to disallow it. It'd be bad to assume all VXLAN
must be on the particular port, and equally bad to assume all traffic
for that port is VXLAN (esp. on a host that is not using VXLAN at all,
but very well may want to use a lot of ports, including 8472).

        I think it ought to be fully general -- different devices may
use different ports and one device may use multiple listeners on different
ports (to split flows for security, load balancing, or whatever).
        I'd make it a per-device function interface that gives you a port 
list
for that device (e.g., an array and length or count). Right now, all 
devices
would return the single module parameter value, but in the future those 
ought
to be capable of being entirely distinct lists of ports.

                                                                +-DLS

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

[Jesse Gross]

On Wed, Mar 27, 2013 at 12:01 PM, David Stevens <dlstevens@us.ibm.com> wrote:
> netdev-owner@vger.kernel.org wrote on 03/27/2013 02:32:59 PM:
>
>> 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.
>
>         I guess you mean you need to find it within the kernel.
>
>         I think whether or not it remains a single port for the machine,
> it would be just silly to make it a fixed port, period. Virtually any
> service allows an administrator to specify an alternate port to run a
> service on.
>         I think one of the primary reasons is that you may want to run
> more than one instance on the same host (e.g., a sandbox installation
> alongside a production installation) -- a capability not there now,
> even though you can specify an alternate port now.
>         But if for whatever reason an adminstrator cares that it uses
> a particular port number, even in a single instance, there is no
> technical reason to disallow it. It'd be bad to assume all VXLAN
> must be on the particular port, and equally bad to assume all traffic
> for that port is VXLAN (esp. on a host that is not using VXLAN at all,
> but very well may want to use a lot of ports, including 8472).
>
>         I think it ought to be fully general -- different devices may
> use different ports and one device may use multiple listeners on different
> ports (to split flows for security, load balancing, or whatever).
>         I'd make it a per-device function interface that gives you a port
> list
> for that device (e.g., an array and length or count). Right now, all
> devices
> would return the single module parameter value, but in the future those
> ought
> to be capable of being entirely distinct lists of ports.

Agreed, the likelihood of a single port winning in the foreseeable
future seems low and not really consistent with the usage of other L4
ports.  Even settling on a single tunneling protocol is unlikely to
happen, so I don't think this problem is specific to VXLAN.  From a
layering perspective, it also seems better to have the protocol
implementation tell the driver what to use rather than inferring it
the other way around.

As far as GRO/RPS, we really want to do this as early in the
processing path as possible and not wait until the socket lookup since
the more work we do first, the less the benefit.  I think the position
in the stack for both the hardware and software versions are very
analogous.