netdev - RE: [PATCH net-next 1/5] vxlan: Make VXLAN default UDP port number available for others

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]

Date:	Tue, 11 Mar 2014 07:22:31 +0000
From:	Shahed Shaikh <shahed.shaikh@...gic.com>
To:	Or Gerlitz <or.gerlitz@...il.com>,
	Joseph Gasparakis <joseph.gasparakis@...el.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	"Stephen Hemminger (stephen@...workplumber.org)" 
	<stephen@...workplumber.org>
CC:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Dept-HSG Linux NIC Dev <Dept-HSGLinuxNICDev@...gic.com>
Subject: RE: [PATCH net-next 1/5] vxlan: Make VXLAN default UDP port number
 available for others

> -----Original Message-----
> From: Or Gerlitz [mailto:or.gerlitz@...il.com]
> Sent: Tuesday, March 11, 2014 12:12 PM
> To: Shahed Shaikh; Joseph Gasparakis; John Fastabend
> Cc: David Miller; netdev; Dept-HSG Linux NIC Dev
> Subject: Re: [PATCH net-next 1/5] vxlan: Make VXLAN default UDP port
> number available for others
> 
...
> >> >
> >> > Although vxlan module has capability to notify udp ports to other
> >> > interested net devices using .ndo_add_rx_vxlan_port and
> >> > .ndo_del_rx_vxlan_port, there could be some devices which support
> >> > vxlan offload but not interested in updating udp port numbers.
> >> > This may be because some hardware do not support programming
> >> > multiple udp ports and their drivers may decide to program only
> >> > default udp port into adapter. So that adapter, at least, can do
> >> > offloading for default udp port number.
> >>
> >> Indeed, but the default port number can be unused while another port
> >> is used. The ndo will be invoked only behalf of an actual instancing
> >> of udp port for listener socket (== destination port you want the hw
> >> to indentify), what's wrong with support this ndo also for devices
> >> that supported limited (say
> >> one) such port?
> >
> >
> >  If driver implements .ndo for udp port and user creates multiple
> > vxlan device with different udp ports, it may end up programming the
> > udp port which may not go through the adapter and no offload will
> > happen. OTOH, if drive does not implement .ndo and if user is aware
> > that driver  is capable of offloading for default port, he can at least crate
> vxlan device on top of qlcnic interface  with default udp port. So, there is no
> chance for other udp port numbers to replace default udp port and disturb
> offloading.
> 
> I see your point, but doesn't this suggests we need to somehow enhance
> the current framework to let drivers know which vxlan traffic is expected to
> be received over them according to the current routing rules?

Agree. Because of this limitation I used default udp port for offloading.

> I understand this is a bit tricky because  vxlan and routing  are l3 constructs
> while drivers deal with l2, John/Joseph - what's your thinking here?

Yes. May be John, Joseph or Stephen can suggest on this.

Thanks,
Shahed

--
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