netdev - Re: [patch net-next v3 15/17] bridge: add new hwmode swdev

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]

Message-ID: <20141125161733.GI27416@gospo.rtplab.test>
Date:	Tue, 25 Nov 2014 11:17:33 -0500
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
	davem@...emloft.net, nhorman@...driver.com, andy@...yhouse.net,
	tgraf@...g.ch, dborkman@...hat.com, ogerlitz@...lanox.com,
	jesse@...ira.com, pshelar@...ira.com, azhou@...ira.com,
	ben@...adent.org.uk, stephen@...workplumber.org,
	jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
	xiyou.wangcong@...il.com, john.r.fastabend@...el.com,
	edumazet@...gle.com, jhs@...atatu.com, sfeldma@...il.com,
	f.fainelli@...il.com, linville@...driver.com, jasowang@...hat.com,
	ebiederm@...ssion.com, nicolas.dichtel@...nd.com,
	ryazanov.s.a@...il.com, buytenh@...tstofly.org,
	aviadr@...lanox.com, nbd@...nwrt.org, alexei.starovoitov@...il.com,
	Neil.Jerram@...aswitch.com, ronye@...lanox.com,
	simon.horman@...ronome.com, alexander.h.duyck@...hat.com,
	john.ronciak@...el.com, mleitner@...hat.com, shrijeet@...il.com,
	bcrl@...ck.org
Subject: Re: [patch net-next v3 15/17] bridge: add new hwmode swdev

On Tue, Nov 25, 2014 at 08:03:11AM -0800, Roopa Prabhu wrote:
> On 11/25/14, 2:28 AM, Jiri Pirko wrote:
> >From: Scott Feldman <sfeldma@...il.com>
> >
> >Current hwmode settings are "vepa" or "veb".  These are for NIC interfaces
> >with basic bridging function offloaded to HW.  Add new "swdev" for full
> >switch device offloads.
> 
> still voting for a generic feature flag like NETIF_F_HW_OFFLOAD for use by
> bridge/bond/vxlan. I can resubmit my patch that does this.

I know it is _early_ to propose this, but I would even suggest this:

diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 8e30685..6cea162 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -124,6 +124,7 @@ enum {
 #define NETIF_F_HW_VLAN_STAG_TX	__NETIF_F(HW_VLAN_STAG_TX)
 #define NETIF_F_HW_L2FW_DOFFLOAD	__NETIF_F(HW_L2FW_DOFFLOAD)
 #define NETIF_F_BUSY_POLL	__NETIF_F(BUSY_POLL)
+#define NETIF_F_HW_SWITCHING	__NETIF_F(HW_SWITCHING)
 
 /* Features valid for ethtool to change */
 /* = all defined minus driver/device-class-related */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 2cb7724..ca5a5e1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1508,7 +1508,7 @@ struct net_device {
 	netdev_features_t	hw_features;
 	netdev_features_t	wanted_features;
 	netdev_features_t	vlan_features;
-	netdev_features_t	hw_enc_features;
+	netdev_features_t	offload_features;
 	netdev_features_t	mpls_features;
 
 	int			ifindex;
> >
> >Signed-off-by: Scott Feldman <sfeldma@...il.com>
> >Signed-off-by: Jiri Pirko <jiri@...nulli.us>
> >---
> >new in v3
> >---
> >  include/uapi/linux/if_bridge.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> >diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> >index da17e45..60425ca 100644
> >--- a/include/uapi/linux/if_bridge.h
> >+++ b/include/uapi/linux/if_bridge.h
> >@@ -105,6 +105,7 @@ struct __fdb_entry {
> >  #define BRIDGE_MODE_VEB		0	/* Default loopback mode */
> >  #define BRIDGE_MODE_VEPA	1	/* 802.1Qbg defined VEPA mode */
> >+#define BRIDGE_MODE_SWDEV       2       /* Full switch device offload */
> >  /* Bridge management nested attributes
> >   * [IFLA_AF_SPEC] = {
> 
--
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