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
| ||
|
Message-ID: <6AE768456CEC4B4A9B2248CB6B87EB3E1BC95245@SJEXCHMB05.corp.ad.broadcom.com> 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
Powered by blists - more mailing lists