netdev - RE: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set

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:	Sat, 6 Dec 2014 03:06:43 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	John Fastabend <john.fastabend@...il.com>,
	Netdev <netdev@...r.kernel.org>
CC:	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Scott Feldman <sfeldma@...il.com>,
	Jirí Pírko <jiri@...nulli.us>,
	"Jamal Hadi Salim" <jhs@...atatu.com>,
	Benjamin LaHaise <bcrl@...ck.org>, Thomas Graf <tgraf@...g.ch>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	John Linville <linville@...driver.com>,
	"nhorman@...driver.com" <nhorman@...driver.com>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	"vyasevic@...hat.com" <vyasevic@...hat.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
	Aviad Raveh <aviadr@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>,
	"shm@...ulusnetworks.com" <shm@...ulusnetworks.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>
Subject: RE: [PATCH 2/3] bridge: offload bridge port attributes to switch
 asic if feature flag set



> -----Original Message-----
> From: John Fastabend [mailto:john.fastabend@...il.com]
> Sent: Friday, December 05, 2014 6:46 PM
> To: Arad, Ronen
> Cc: Roopa Prabhu; Scott Feldman; Netdev; Jirí Pírko; Jamal Hadi Salim;
> Benjamin LaHaise; Thomas Graf; stephen@...workplumber.org; John
> Linville; nhorman@...driver.com; Nicolas Dichtel; vyasevic@...hat.com;
> Florian Fainelli; buytenh@...tstofly.org; Aviad Raveh; David S. Miller;
> shm@...ulusnetworks.com; Andy Gospodarek
> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
> if feature flag set
> 
> On 12/05/2014 05:04 PM, Arad, Ronen wrote:
> > I have another case of propagation which is not covered by the proposed
> patch.
> > A recent patch introduced default_pvid attribute for a bridge (so far
> supported only via sysfs and not via netlink).
> > When a port joins a bridge, it inherits a PVID from the default_pvid of the
> bridge.
> > The bridge driver propagates that to the newly created net_bridge_port.
> This is done in br_vlan.c:
> >
> > int nbp_vlan_init(struct net_bridge_port *p) {
> > 	int rc = 0;
> >
> > 	if (p->br->default_pvid) {
> > 		rc = nbp_vlan_add(p, p->br->default_pvid,
> > 				  BRIDGE_VLAN_INFO_PVID |
> > 				  BRIDGE_VLAN_INFO_UNTAGGED);
> > 	}
> >
> > 	return rc;
> > }
> >
> > When L2 switching is offloaded to the HW, this PVID setting need to be
> propagated. However, it does not come via ndo_bridge_setlink. The
> proposed propagation at br_setlink or an up level one at rtnetlink are not
> capable of handling this case.
> > One possible way for handling that is to replace the call to
> > nbp_vlan_add with a call to a new function let's say int
> > br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> This function will compose a netlink message with VLAN filtering information
> (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload
> support proposed by Roopa.
> >
> 
> No, we shouldn't be crafting netlink messages in the kernel just re-inject
> them into an interface. Really the setlink/dellink interface should be cleaned
> up so that it no longer consumes raw netlink messages.
> 
> Then either (a) add another parameter to the setlink ops or (b) create a new
> op for it.
> 
> I think cleaning up the setlink/dellink hooks is on the TBD list already.
> 
This would be a lot cleaner even though there could be loss of flexibility. Fixed argument interface will not be extensible.
Will the non-Netlink based driver setlink/dellink hooks be TLV based or take a pointer to a single struct with some indication of what is actually populated there? 
> 
> > If this is an acceptable course of action, I could work on such patch.
> >
> >
> 
> [...]
> 
> Thanks,
> John
> 
> --
> John Fastabend         Intel Corporation