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-next>] [day] [month] [year] [list]
Date:	Tue, 29 May 2012 20:06:54 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	krkumar2@...ibm.com, hadi@...erus.ca, shemminger@...tta.com,
	mst@...hat.com, buytenh@...tstofly.org, eilong@...adcom.com
Cc:	sri@...ibm.com, gregory.v.rose@...el.com, netdev@...r.kernel.org,
	bhutchings@...arflare.com, jeffrey.t.kirsher@...el.com,
	eric.w.multanen@...el.com
Subject: [RFC PATCH v1 0/3] Expose switching attributes via PF_BRIDGE

This series decouples the remaining netlink PF_BRIDGE messages
from the bridging module and moves them into rtnetlink proper.
By doing this we can use these netlink messages to handle any
type of bridge and extend the attributes as needed.

I hope this resolves some of the concerns with the DSA patch
below and expect the attached series can be extended to
support the DSA infrastructure as needed:

http://patchwork.ozlabs.org/patch/16578/

Also this should resolve a patch here that tried to expose
the switching modes but did so using a device specific hook:

http://lists.openwall.net/netdev/2012/04/16/10

I've used a hacked version of the 'bridge' tool Stephen
Hemminger submitted as an RFC some months back to test this
the output looks like this:

[root@...dev1-dcblab iproute2]# ./br/br bridge show
eth2: bridge mode: VEB		embedded
eth3: bridge mode: VEB		embedded
[root@...dev1-dcblab iproute2]# ./br/br bridge mode dev eth2 mode vepa
[root@...dev1-dcblab iproute2]# ./br/br bridge show
eth2: bridge mode: VEPA		embedded
eth3: bridge mode: VEB		embedded

I could have just added a ndo op and IFLA_XXX message to
set the switching mode but IMHO this is not going to scale
as more bridging functionality becomes offloaded. The DSA
example is a case where we already have a fully offloaded
switch. Any solution we come up with should support both
embedded switches and SW switches.

Any comments would be appreciated Thanks!

---

John Fastabend (3):
      ixgbe: add setlink, getlink support to ixgbe and ixgbevf
      net: add VEPA, VEB bridge mode
      net: create generic bridge ops


 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c     |  100 +++++++++++++++
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c    |    3 
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   10 ++
 include/linux/if_link.h                           |   16 ++
 include/linux/netdevice.h                         |   10 ++
 net/bridge/br_device.c                            |    2 
 net/bridge/br_netlink.c                           |   75 ++---------
 net/bridge/br_private.h                           |    3 
 net/core/rtnetlink.c                              |  137 +++++++++++++++++++++
 9 files changed, 291 insertions(+), 65 deletions(-)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ