netdev - Re: [net-next 1/2] vxlan: Notify drivers for listening UDP port changes

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: <1377690212.2552.12.camel@deadeye.wl.decadent.org.uk>
Date:	Wed, 28 Aug 2013 12:43:32 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Cong Wang <xiyou.wangcong@...il.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: [net-next  1/2] vxlan: Notify drivers for listening UDP port
 changes

On Wed, 2013-08-28 at 07:47 +0000, Cong Wang wrote:
> On Wed, 28 Aug 2013 at 04:46 GMT, Jeff Kirsher <jeffrey.t.kirsher@...el.com> wrote:
> > From: Joseph Gasparakis <joseph.gasparakis@...el.com>
> >
> > This patch adds two more ndo ops: ndo_add_rx_vxlan_port() and
> > ndo_del_rx_vxlan_port().
> >
> > Drivers can get notifications through the above functions about changes
> > of the UDP listening port of VXLAN. Also, when physical ports come up,
> > now they can call vxlan_get_rx_port() in order to obtain the port number(s)
> > of the existing VXLAN interface in case they already up before them.
> >
> > This information about the listening UDP port would be used for VXLAN
> > related offloads.
> >
> 
> Since this is a notification, how about adding a new NETDEV_* event
> rather than adding two new ndo_* ops?

Since this is a change at the netns (rather than net device) level, it
makes more logical sense to send a single notification for each change.
But any driver that needs to know about this would then need to iterate
over its own devices (limited to the given netns) - which means writing
the same iteration in each driver that supports this (with added
filtering by driver), or adding a list of devices to each driver.  So
practically it seems better to do this iteration in the core as
proposed.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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