netdev - RE: [net-next PATCH v2 0/3] extend set/get netlink for embedded

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Oct 2012 21:09:35 +0000
From:	"Ariel Elior" <ariele@...adcom.com>
To:	"'John Fastabend'" <john.r.fastabend@...el.com>,
	"shemminger@...tta.com" <shemminger@...tta.com>,
	"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"vyasevic@...hat.com" <vyasevic@...hat.com>
cc:	"jhs@...atatu.com" <jhs@...atatu.com>,
	"chrisw@...hat.com" <chrisw@...hat.com>,
	"krkumar2@...ibm.com" <krkumar2@...ibm.com>,
	"samudrala@...ibm.com" <samudrala@...ibm.com>,
	"peter.p.waskiewicz.jr@...el.com" <peter.p.waskiewicz.jr@...el.com>,
	"jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"bhutchings@...arflare.com" <bhutchings@...arflare.com>,
	"gregory.v.rose@...el.com" <gregory.v.rose@...el.com>,
	"Eilon Greenstein" <eilong@...adcom.com>
Subject: RE: [net-next PATCH v2 0/3] extend set/get netlink for embedded



> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of John Fastabend
> Sent: Wednesday, October 24, 2012 8:13 PM
> To: shemminger@...tta.com; buytenh@...tstofly.org;
> davem@...emloft.net; vyasevic@...hat.com
> Cc: jhs@...atatu.com; chrisw@...hat.com; krkumar2@...ibm.com;
> samudrala@...ibm.com; peter.p.waskiewicz.jr@...el.com;
> jeffrey.t.kirsher@...el.com; netdev@...r.kernel.org;
> bhutchings@...arflare.com; gregory.v.rose@...el.com; Eilon Greenstein
> Subject: [net-next PATCH v2 0/3] extend set/get netlink for embedded
> 
> This extends the PF_BRIDGE setlink and getlink so that they can be used
> generically outside of the Linux bridge module. Doing this allows
> embedded devices to use the same netlink interface that the software
> bridge is currently using.
> 
> In this patchset I opted to create two new ndo ops ndo_bridge_setlink and
> ndo_bridge_getlink. These ops pass the nlmsghdr to the device for
> handling. The netlink message is extended to support nested IFLA_AF_SPEC
> attributes. A IFLA_BRIDGE_FLAGS attribute is used to determine the target
> of the message either a master netdev is the target or the target is "self"
> indicating the target is the netdev.
> In this way we can send netlink msg to an embedded device or the linux sw
> bridge or both. If the set completes sucessfully the flag is cleared in this way
> we can learn what failed in the both case.
> This scheme is similar to how FDB updates are handled. If no flag attribute is
> present the message is sent to the master device to support the existing
> messages.
> 
> An initial IFLA_BRIDGE_MODE attribute is added to indicate if the bridge is
> in a VEPA mode or VEB mode. This is most useful for SR-IOV device and can
> be used to indicate support for VF to VF or VF to PF traffic. Without this we
> have no way of knowing this other then trial and error because not all
> hardware supports this.
> 
> In the future additional attributes can be added to handle other attributes.
> We could for example move some of the linux bridge sysfs attributes here if
> we want a netlink interface for them.
> This should also allow DSA switches to use the bridging tools.
> See RFC patch from Lennert
> 
> http://patchwork.ozlabs.org/patch/16578/
> 
> I could have simply added the VEPA attribute handling to the
> rtnl_setlink() routine but it seemed like a good feature to have all the
> bridging events and configuration on the same type. Also this should allow
> more powerful offloaded switches like the hardware supported via DSA
> access to the bridge control interface.
> 
> Also I think this interface should allow Vlad to add his port based VLAN
> interface here as well.
> 
> Any feedback/criticism appreciated thanks!
> 


This series looks fine from bnx2x point of view.
The dynamic change from VEB to VEPA will require a firmware change,
so we might arrive a little late for the party.
Ariel