netdev - Re: HW bridging support using notifiers?

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:	Fri, 3 Oct 2014 10:22:15 -0400
From:	Benjamin LaHaise <bcrl@...ck.org>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, jiri@...nulli.us,
	stephen@...workplumber.org, andy@...yhouse.net, tgraf@...g.ch,
	nbd@...nwrt.org, john.r.fastabend@...el.com, edumazet@...gle.com,
	vyasevic@...hat.com, buytenh@...tstofly.org,
	sfeldma@...ulusnetworks.com, Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: HW bridging support using notifiers?

Hi Florian et al,

On Thu, Oct 02, 2014 at 06:48:57PM -0700, Florian Fainelli wrote:
> Hi all,
> 
> I am taking a look at adding HW bridging support to DSA, in way that's
> usable outside of DSA.

I've been working on support for the RTL8366S switch, and our work is 
directly overlapping here.  I actually have something that is working at 
configuring port and tag based vlans on the RTL8366S.  I'll try to clean 
up the code to post something for discussion over the next couple of days.

> Lennert's approach in 2008 [1] looks conceptually good to me,as he
> noted, it uses a bunch of new ndo's which is not only limiting to one
> ndo implementer per struct net_device, but also is mostly consuming the
> information from the bridge layer, while the ndo is an action

I think having ndo implementer methods for hardware switch offloads makes 
more sense.  Such a scheme is needed in order to implement the stacking of 
devices that is required in order to transparently handle configuration of 
vlans on switch ports where the 8021q device has to pass on the vlan tag 
to the switch device.  The ndo methods do perform an action of causing the 
switch to be configured to match the bridge config.  Additionally, they 
can be used to veto changes that cannot be offloaded to hardware -- this 
(configurable) behaviour is desired by some users of these APIs who wish 
to be made aware when a particuarly configuration is not supported by the 
underlying hardware.

> So here's what I am up to now:
> 
> - use the NETDEV_JOIN notifier to discover when a bridge port is added
> - use the NETDEV_LEAVE notifier, still need to verify this does not
> break netconsole as indicated in net/bridge/br_if.c
> - use the NETDEV_CHANGEINFODATA notifier to notify about STP state changes

To me, notifiers are the wrong model for join and leave.  Implementing 
stacking on top of notifiers is somewhat more complicated.  Here are the 
ndo methods I've implemented so far which are sufficient for basic config 
of the RTL8366S.  They're fairly similar to those in [1].

+	int			(*ndo_join_bridge)(struct net_bridge *bridge,
+						   struct net_device *dev,
+						   int *switch_nr,
+						   int *switch_port_nr,
+						   int vlan);
+	int			(*ndo_leave_bridge)(struct net_bridge *bridge,
+						    struct net_device *dev,
+						    int switch_nr,
+						    int switch_port_nr,
+						    int vlan);
+	int			(*ndo_flood_xmit)(struct switch_info *dev,
+						  struct sk_buff *skb,
+						  u64 port_mask);

There are a couple of important points here.  In the case of joining and 
leaving a bridge, the bridge needs to be provided with information it can 
use to identify switch ports.  This is needed in order to offload the 
flooding of packets to multiple ports, as otherwise the Linux bridge code 
doesn't have any way to figure out which packets can be merged into a 
single transmit via the ndo_flood_xmit() method.

> Now, this raises a bunch of questions:
> 
> - we would need a getter to return the stp state of a given network
> device when called with NETDEV_CHANGEINFODATA, is that acceptable? This
> would be the first function exported by the bridge layer to expose
> internal data

I have yet to dig into STP, so I'll refrain from commenting on these parts 
for now.

> NB: this also raises the question of the race condition and locking
> within br_set_stp_state() and when the network devices notifier callback
> runs
U
> - or do we need a new network device notifier accepting an opaque
> pointer which could provide us with the data we what, something like
> this: call_netdevices_notifier_data(NETDEV_CHANGEINFODATA, dev, info),
> where info would be a structure/union telling what's this data about
> 
> Let me know what you think, thanks!
> 
> [1]: http://patchwork.ozlabs.org/patch/16578/

Thanks for the pointer to this.  Cheers!

		-ben

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

-- 
"Thought is the essence of where you are now."
--
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