introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload

So this can be reused for identification of other "items" as well.

net/core/net-sysfs.c +1 -1

index 9dd0669..55dc4da 100644
@@ -387,7 +387,7 @@ static ssize_t phys_port_id_show(struct device *dev,
  		return restart_syscall();
 
  	if (dev_isalive(netdev)) {
-		struct netdev_phys_port_id ppid;
+		struct netdev_phys_item_id ppid;
 
  		ret = dev_get_phys_port_id(netdev, &ppid);
  		if (!ret)

net/core/rtnetlink.c +1 -1

index a688268..1087c6d 100644
@@ -868,7 +868,7 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
  	       + rtnl_port_size(dev, ext_filter_mask) /* IFLA_VF_PORTS + IFLA_PORT_SELF */
  	       + rtnl_link_get_size(dev) /* IFLA_LINKINFO */
  	       + rtnl_link_get_af_size(dev) /* IFLA_AF_SPEC */
-	       + nla_total_size(MAX_PHYS_PORT_ID_LEN); /* IFLA_PHYS_PORT_ID */
+	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_PORT_ID */
  }
 

static int rtnl_vf_ports_fill(struct sk_buff *skb, struct net_device *dev)

net/core/rtnetlink.c +1 -1

@@ -952,7 +952,7 @@ static int rtnl_port_fill(struct sk_buff *skb, struct net_device *dev,
  static int rtnl_phys_port_id_fill(struct sk_buff *skb, struct net_device *dev)
  {
  	int err;
-	struct netdev_phys_port_id ppid;
+	struct netdev_phys_item_id ppid;
 
  	err = dev_get_phys_port_id(dev, &ppid);
  	if (err) {

wouldnt this just break an existing ABI? You may need to introduce a new attribute.

From: Jamal Hadi Salim <[email protected]>
Date: Sun, 09 Nov 2014 22:35:12 -0500

Quoted 2 lines

wouldnt this just break an existing ABI? You may need to introduce a new attribute.

He isn't breaking anything Jamal, he's just changing the internal macro name we use for the attribute's maximum length.

Quoted 8 lines · David Miller

From: Jamal Hadi Salim <[email protected]>
Date: Sun, 09 Nov 2014 22:35:12 -0500

Quoted 2 lines

wouldnt this just break an existing ABI? You may need to introduce a new attribute.

He isn't breaking anything Jamal, he's just changing the internal macro name we use for the attribute's maximum length.

It is a _user space visible rename_, how about:

#define MAX_PHYS_ITEM_ID_LEN 32
#define MAX_PHYS_PORT_ID_LEN MAX_PHYS_ITEM_ID_LEN

I did miss the fact that the size didnt change.

$ git grep -n MAX_PHYS_PORT_ID_LEN
include/linux/netdevice.h:756:#define MAX_PHYS_PORT_ID_LEN 32
include/linux/netdevice.h:762:  unsigned char id[MAX_PHYS_PORT_ID_LEN];
net/core/rtnetlink.c:871:              +
nla_total_size(MAX_PHYS_PORT_ID_LEN); /* IFLA_PHYS_PORT_ID */
net/core/rtnetlink.c:1199:      [IFLA_PHYS_PORT_ID]     = { .type =
NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },

... and based on commit 66cae9ed6bc4 ("rtnl: export physical port id via RT netlink") only exported as read-only.

It is a _user space visible rename_, how about:

#define MAX_PHYS_ITEM_ID_LEN 32
#define MAX_PHYS_PORT_ID_LEN MAX_PHYS_ITEM_ID_LEN

I did miss the fact that the size didnt change.

Quoted 32 lines · Jiri Pirko

So this can be reused for identification of other "items" as well.

net/core/net-sysfs.c +1 -1

index 9dd0669..55dc4da 100644
@@ -387,7 +387,7 @@ static ssize_t phys_port_id_show(struct device *dev,
 		return restart_syscall();
 
 	if (dev_isalive(netdev)) {
-		struct netdev_phys_port_id ppid;
+		struct netdev_phys_item_id ppid;
 
 		ret = dev_get_phys_port_id(netdev, &ppid);
 		if (!ret)

net/core/rtnetlink.c +1 -1

index a688268..1087c6d 100644
@@ -868,7 +868,7 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
 	       + rtnl_port_size(dev, ext_filter_mask) /* IFLA_VF_PORTS + IFLA_PORT_SELF */
 	       + rtnl_link_get_size(dev) /* IFLA_LINKINFO */
 	       + rtnl_link_get_af_size(dev) /* IFLA_AF_SPEC */
-	       + nla_total_size(MAX_PHYS_PORT_ID_LEN); /* IFLA_PHYS_PORT_ID */
+	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_PORT_ID */
 }
 

[...]

Quoted 8 lines

static int rtnl_vf_ports_fill(struct sk_buff *skb, struct net_device *dev)

net/core/rtnetlink.c +1 -1

@@ -952,7 +952,7 @@ static int rtnl_port_fill(struct sk_buff *skb, struct net_device *dev,
 static int rtnl_phys_port_id_fill(struct sk_buff *skb, struct net_device *dev)
 {
 	int err;
-	struct netdev_phys_port_id ppid;
+	struct netdev_phys_item_id ppid;
 

net/core/rtnetlink.c static const struct nla_policy ifla_policy[IFLA_MAX+1] = { · line 1201

Quoted 10 lines

net/core/rtnetlink.c +1 -1

 	err = dev_get_phys_port_id(dev, &ppid);
 	if (err) {

@@ -1196,7 +1196,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
 	[IFLA_PROMISCUITY]	= { .type = NLA_U32 },
 	[IFLA_NUM_TX_QUEUES]	= { .type = NLA_U32 },
 	[IFLA_NUM_RX_QUEUES]	= { .type = NLA_U32 },
-	[IFLA_PHYS_PORT_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },
+	[IFLA_PHYS_PORT_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
 	[IFLA_CARRIER_CHANGES]	= { .type = NLA_U32 },  /* ignored */
 };

wouldnt this just break an existing ABI? You may need to introduce a new attribute.

cheers,
jamal

Quoted 4 lines · Jiri Pirko

Mon, Nov 10, 2014 at 04:35:12AM CET, [email protected] wrote:

I don't see a reason why this would break kabi:

include/linux/netdevice.h struct netdev_fcoe_hbainfo { · line 756

Quoted 3 lines

include/linux/netdevice.h +1 -1

-#define MAX_PHYS_PORT_ID_LEN 32
+#define MAX_PHYS_ITEM_ID_LEN 32

refer to my response to Dave. Just define MAX_PHYS_PORT_ID_LEN to MAX_PHYS_ITEM_ID_LEN so people dont have to change their code because a name change.

cheers,
jamal

Jamal, please look at the patch & code. MAX_PHYS_PORT_ID_LEN is in include/linux/netdevice.h which is not part of user exported api.

Quoted 4 lines

Mon, Nov 10, 2014 at 04:35:12AM CET, [email protected] wrote:

I don't see a reason why this would break kabi:

include/linux/netdevice.h struct netdev_fcoe_hbainfo { · line 756

Quoted 3 lines

include/linux/netdevice.h +1 -1

-#define MAX_PHYS_PORT_ID_LEN 32
+#define MAX_PHYS_ITEM_ID_LEN 32

refer to my response to Dave. Just define MAX_PHYS_PORT_ID_LEN to MAX_PHYS_ITEM_ID_LEN so people dont have to change their code because a name change.

From: Jamal Hadi Salim <[email protected]>

Jamal, this is really driving me crazy, this is a non-issue.

So this can be reused for identification of other "items" as well.

Signed-off-by Jiri Pirko <[email protected]>

---

The goal of this is to provide a possibility to support various switch chips. Drivers should implement relevant ndos to do so. Now there is only one ndo defined:
- for getting physical switch id is in place.

Note that user can use random port netdevice to access the switch.

Signed-off-by Jiri Pirko <[email protected]>

---
  Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
  MAINTAINERS                            |  7 ++++
  include/linux/netdevice.h              | 10 ++++++
  include/net/switchdev.h                | 30 +++++++++++++++++
  net/Kconfig                            |  1 +
  net/Makefile                           |  3 ++
  net/switchdev/Kconfig                  | 13 ++++++++
  net/switchdev/Makefile                 |  5 +++
  net/switchdev/switchdev.c              | 33 +++++++++++++++++++
  9 files changed, 161 insertions(+)

create mode 100644 Documentation/networking/switchdev.txt create mode 100644 include/net/switchdev.h create mode 100644 net/switchdev/Kconfig
create mode 100644 net/switchdev/Makefile
create mode 100644 net/switchdev/switchdev.c

Documentation/networking/switchdev.txt new file +43 -0

new file mode 100644
index 0000000..98be76c
@@ -0,0 +1,59 @@
+Switch (and switch-ish) device drivers HOWTO
+===========================
+
+Please note that the word "switch" is here used in very generic meaning.
+This include devices supporting L2/L3 but also various flow offloading chips,
+including switches embedded into SR-IOV NICs.
+
+Lets describe a topology a bit. Imagine the following example:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       port1 port2 port3 port4 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  NIC0 NIC1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+In this example, there are two independent lines between the switch silicon
+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
+separate from the switch driver. SOME switch chip is by managed by a driver
+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
+connected to some other type of bus.
+
+Now, for the previous example show the representation in kernel:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  eth0 eth1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
+created for each port of a switch. These netdevices are instances
+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"

Quoted 74 lines · Jiri Pirko

The goal of this is to provide a possibility to support various switch chips. Drivers should implement relevant ndos to do so. Now there is only one ndo defined:
- for getting physical switch id is in place.

Note that user can use random port netdevice to access the switch.

Signed-off-by Jiri Pirko <[email protected]>

---
 Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
 MAINTAINERS                            |  7 ++++
 include/linux/netdevice.h              | 10 ++++++
 include/net/switchdev.h                | 30 +++++++++++++++++
 net/Kconfig                            |  1 +
 net/Makefile                           |  3 ++
 net/switchdev/Kconfig                  | 13 ++++++++
 net/switchdev/Makefile                 |  5 +++
 net/switchdev/switchdev.c              | 33 +++++++++++++++++++
 9 files changed, 161 insertions(+)
 create mode 100644 Documentation/networking/switchdev.txt
 create mode 100644 include/net/switchdev.h
 create mode 100644 net/switchdev/Kconfig
 create mode 100644 net/switchdev/Makefile
 create mode 100644 net/switchdev/switchdev.c

Documentation/networking/switchdev.txt new file +43 -0

new file mode 100644
index 0000000..98be76c
@@ -0,0 +1,59 @@
+Switch (and switch-ish) device drivers HOWTO
+===========================
+
+Please note that the word "switch" is here used in very generic meaning.
+This include devices supporting L2/L3 but also various flow offloading chips,
+including switches embedded into SR-IOV NICs.
+
+Lets describe a topology a bit. Imagine the following example:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       port1 port2 port3 port4 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  NIC0 NIC1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+In this example, there are two independent lines between the switch silicon
+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
+separate from the switch driver. SOME switch chip is by managed by a driver
+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
+connected to some other type of bus.
+
+Now, for the previous example show the representation in kernel:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  eth0 eth1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
+created for each port of a switch. These netdevices are instances
+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"

Documentation/networking/switchdev.txt line 53

Quoted 10 lines

Documentation/networking/switchdev.txt new file +10 -0

+of the switch chip. eth0 and eth1 are instances of some other existing driver.
+
+The only difference of the switch-port netdevice from the ordinary netdevice
+is that is implements couple more NDOs:
+
+	ndo_sw_parent_get_id - This returns the same ID for two port netdevices
+			       of the same physical switch chip. This is
+			       mandatory to be implemented by all switch drivers
+			       and serves the caller for recognition of a port
+			       netdevice.

What is the connection between ndo_sw_parent_get_id and ndo_get_phys_port_id(). I'm having a bit of trouble teasing this out.

For example here is my ascii art for a SR-IOV NIC,

eth0 eth1 eth2
| | |
| | |
PF VF VF

  +----+---------+--------+----+
  |       embedded bridge      |
  +-------------+--------------+
                |

port

that can do switching between the various uplinks and downlinks. In IEEE 802.1Q language the embedded bridge acts like an edge relay. At least that seems to be the current state of the art for SR-IOV. Edge relay just means it has a single uplink port to the network and multiple downlinks and also isn't required to do learning and run loop detection protocols STP, et. al.

Also there are multi-function devices that look the same except replace the VFs with PFs. It seems to be a common mode for NICs that do the iSCSI offloads with storage functions.

When something is an embedded bridge vs a SOME switch chip is not entirely clear.

My understanding is use ndo_sw_parent_get_id() when you have multiple physical ports all connected to a single switch object. When you have a single port connected to multiple PCIE functions or queues representing a netdev (e.g. macvlan offload) use the ndo_get_phys_port_id(). Just want to be sure we are on the same page here.

Otherwise patch looks good. I think we can clear the above up with an addition to the documentation. Could go in after the initial set and be OK with me.

IMO this patch is needed otherwise user space is at a complete loss on trying to figure out how netdevs map to switch silicon. You could have reused ndo_get_phys_port_id() perhaps but then I think user space may get confused by SR-IOV/VMDQ/etc ports attached to a switch silicon. For .02$ having a new distinct identifier is cleaner.

Documentation/networking/switchdev.txt line 59

Quoted 8 lines

Documentation/networking/switchdev.txt new file +6 -0

+	ndo_sw_parent_* - Functions that serve for a manipulation of the switch
+			  chip itself (it can be though of as a "parent" of the
+			  port, therefore the name). They are not port-specific.
+			  Caller might use arbitrary port netdevice of the same
+			  switch and it will make no difference.
+	ndo_sw_port_* - Functions that serve for a port-specific manipulation.

[...]

Thanks,
John

Signature · 1 line

John Fastabend         Intel Corporation

Am 09.11.2014 um 11:51 schrieb Jiri Pirko:

Documentation/networking/switchdev.txt

Quoted 2 lines

Documentation/networking/switchdev.txt +1 -0

+	ndo_sw_parent_get_id - ...

here the ndo is called get_id

but

include/linux/netdevice.h struct net_device_ops { · line 1175

Quoted 7 lines

include/linux/netdevice.h +5 -0

+ *
+ * int (*ndo_sw_parent_id_get)(struct net_device *dev,
+ *			       struct netdev_phys_item_id *psid);

@@ -1168,6 +1174,10 @@ struct net_device_ops {
+	int			(*ndo_sw_parent_id_get)(struct net_device *dev,
+							struct netdev_phys_item_id *psid);

here it is call id_get, which is similar but not the same.

Regards,
M. Braun

The goal of this is to provide a possibility to support various switch chips. Drivers should implement relevant ndos to do so. Now there is only one ndo defined:
- for getting physical switch id is in place.

Note that user can use random port netdevice to access the switch.

Signed-off-by Jiri Pirko <[email protected]>

---
  Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
  MAINTAINERS                            |  7 ++++
  include/linux/netdevice.h              | 10 ++++++
  include/net/switchdev.h                | 30 +++++++++++++++++
  net/Kconfig                            |  1 +
  net/Makefile                           |  3 ++
  net/switchdev/Kconfig                  | 13 ++++++++
  net/switchdev/Makefile                 |  5 +++
  net/switchdev/switchdev.c              | 33 +++++++++++++++++++
  9 files changed, 161 insertions(+)

create mode 100644 Documentation/networking/switchdev.txt create mode 100644 include/net/switchdev.h create mode 100644 net/switchdev/Kconfig
create mode 100644 net/switchdev/Makefile
create mode 100644 net/switchdev/switchdev.c

Documentation/networking/switchdev.txt new file +59 -0

new file mode 100644
index 0000000..98be76c
@@ -0,0 +1,59 @@
+Switch (and switch-ish) device drivers HOWTO
+===========================
+
+Please note that the word "switch" is here used in very generic meaning.
+This include devices supporting L2/L3 but also various flow offloading chips,
+including switches embedded into SR-IOV NICs.
+
+Lets describe a topology a bit. Imagine the following example:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       port1 port2 port3 port4 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  NIC0 NIC1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+In this example, there are two independent lines between the switch silicon
+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
+separate from the switch driver. SOME switch chip is by managed by a driver
+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
+connected to some other type of bus.
+
+Now, for the previous example show the representation in kernel:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  eth0 eth1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
+created for each port of a switch. These netdevices are instances
+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
+of the switch chip. eth0 and eth1 are instances of some other existing driver.
+
+The only difference of the switch-port netdevice from the ordinary netdevice
+is that is implements couple more NDOs:
+
+	ndo_sw_parent_get_id - This returns the same ID for two port netdevices
+			       of the same physical switch chip. This is
+			       mandatory to be implemented by all switch drivers
+			       and serves the caller for recognition of a port
+			       netdevice.
+	ndo_sw_parent_* - Functions that serve for a manipulation of the switch
+			  chip itself (it can be though of as a "parent" of the
+			  port, therefore the name). They are not port-specific.
+			  Caller might use arbitrary port netdevice of the same
+			  switch and it will make no difference.
+	ndo_sw_port_* - Functions that serve for a port-specific manipulation.

MAINTAINERS +7 -0

index 3a41fb0..776e078 100644
@@ -9003,6 +9003,13 @@ F:	lib/swiotlb.c
  F:	arch/*/kernel/pci-swiotlb.c
  F:	include/linux/swiotlb.h
 
+SWITCHDEV
+M:	Jiri Pirko <[email protected]>
+L:	[email protected]
+S:	Supported
+F:	net/switchdev/
+F:	include/net/switchdev.h
+
  SYNOPSYS ARC ARCHITECTURE
  M:	Vineet Gupta <[email protected]>
  S:	Supported

include/linux/netdevice.h +6 -0

index 71922e0..97eade9 100644
@@ -1017,6 +1017,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
   *	performing GSO on a packet. The device returns true if it is
   *	able to GSO the packet, false otherwise. If the return value is
   *	false the stack will do software GSO.
+ *
+ * int (*ndo_sw_parent_id_get)(struct net_device *dev,
+ *			       struct netdev_phys_item_id *psid);
+ *	Called to get an ID of the switch chip this port is part of.
+ *	If driver implements this, it indicates that it represents a port
+ *	of a switch chip.
   */
  struct net_device_ops {
  	int			(*ndo_init)(struct net_device *dev);

include/linux/netdevice.h +1 -0

+#endif
  };
 
  /**

include/net/switchdev.h new file +30 -0

new file mode 100644
index 0000000..79bf9bd
@@ -0,0 +1,30 @@
+/*
+ * include/net/switchdev.h - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _LINUX_SWITCHDEV_H_
+#define _LINUX_SWITCHDEV_H_
+
+#include <linux/netdevice.h>
+
+#ifdef CONFIG_NET_SWITCHDEV
+
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid);
+
+#else
+
+static inline int netdev_sw_parent_id_get(struct net_device *dev,
+					  struct netdev_phys_item_id *psid)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif /* _LINUX_SWITCHDEV_H_ */

net/Kconfig +1 -0

index 99815b5..ff9ffc1 100644
@@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
  source "net/netlink/Kconfig"
  source "net/mpls/Kconfig"
  source "net/hsr/Kconfig"
+source "net/switchdev/Kconfig"
 
  config RPS
  	boolean

net/Makefile +3 -0

index 7ed1970..95fc694 100644
@@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH)	+= openvswitch/
  obj-$(CONFIG_VSOCKETS)	+= vmw_vsock/
  obj-$(CONFIG_NET_MPLS_GSO)	+= mpls/
  obj-$(CONFIG_HSR)		+= hsr/
+ifneq ($(CONFIG_NET_SWITCHDEV),)
+obj-y				+= switchdev/
+endif

net/switchdev/Kconfig new file +13 -0

new file mode 100644
index 0000000..1557545
@@ -0,0 +1,13 @@
+#
+# Configuration for Switch device support
+#
+
+config NET_SWITCHDEV
+	boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
+	depends on INET
+	---help---
+	  This module provides glue between core networking code and device
+	  drivers in order to support hardware switch chips in very generic
+	  meaning of the word "switch". This include devices supporting L2/L3 but
+	  also various flow offloading chips, including switches embedded into
+	  SR-IOV NICs.

net/switchdev/Makefile new file +5 -0

new file mode 100644
index 0000000..5ed63ed
@@ -0,0 +1,5 @@
+#
+# Makefile for the Switch device API
+#
+
+obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o

net/switchdev/switchdev.c new file +33 -0

new file mode 100644
index 0000000..5010f646
@@ -0,0 +1,33 @@
+/*
+ * net/switchdev/switchdev.c - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <net/switchdev.h>
+
+/**
+ *	netdev_sw_parent_id_get - Get ID of a switch
+ *	@dev: port device
+ *	@psid: switch ID
+ *
+ *	Get ID of a switch this port is part of.
+ */
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid)
+{
+	const struct net_device_ops *ops = dev->netdev_ops;
+
+	if (!ops->ndo_sw_parent_id_get)
+		return -EOPNOTSUPP;
+	return ops->ndo_sw_parent_id_get(dev, psid);
+}
+EXPORT_SYMBOL(netdev_sw_parent_id_get);

Quoted 130 lines · Jiri Pirko

The goal of this is to provide a possibility to support various switch chips. Drivers should implement relevant ndos to do so. Now there is only one ndo defined:
- for getting physical switch id is in place.

Note that user can use random port netdevice to access the switch.

Signed-off-by Jiri Pirko <[email protected]>

---
 Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
 MAINTAINERS                            |  7 ++++
 include/linux/netdevice.h              | 10 ++++++
 include/net/switchdev.h                | 30 +++++++++++++++++
 net/Kconfig                            |  1 +
 net/Makefile                           |  3 ++
 net/switchdev/Kconfig                  | 13 ++++++++
 net/switchdev/Makefile                 |  5 +++
 net/switchdev/switchdev.c              | 33 +++++++++++++++++++
 9 files changed, 161 insertions(+)
 create mode 100644 Documentation/networking/switchdev.txt
 create mode 100644 include/net/switchdev.h
 create mode 100644 net/switchdev/Kconfig
 create mode 100644 net/switchdev/Makefile
 create mode 100644 net/switchdev/switchdev.c

Documentation/networking/switchdev.txt new file +59 -0

new file mode 100644
index 0000000..98be76c
@@ -0,0 +1,59 @@
+Switch (and switch-ish) device drivers HOWTO
+===========================
+
+Please note that the word "switch" is here used in very generic meaning.
+This include devices supporting L2/L3 but also various flow offloading chips,
+including switches embedded into SR-IOV NICs.
+
+Lets describe a topology a bit. Imagine the following example:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       port1 port2 port3 port4 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  NIC0 NIC1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+In this example, there are two independent lines between the switch silicon
+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
+separate from the switch driver. SOME switch chip is by managed by a driver
+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
+connected to some other type of bus.
+
+Now, for the previous example show the representation in kernel:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  eth0 eth1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
+created for each port of a switch. These netdevices are instances
+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
+of the switch chip. eth0 and eth1 are instances of some other existing driver.
+
+The only difference of the switch-port netdevice from the ordinary netdevice
+is that is implements couple more NDOs:
+
+	ndo_sw_parent_get_id - This returns the same ID for two port netdevices
+			       of the same physical switch chip. This is
+			       mandatory to be implemented by all switch drivers
+			       and serves the caller for recognition of a port
+			       netdevice.
+	ndo_sw_parent_* - Functions that serve for a manipulation of the switch
+			  chip itself (it can be though of as a "parent" of the
+			  port, therefore the name). They are not port-specific.
+			  Caller might use arbitrary port netdevice of the same
+			  switch and it will make no difference.
+	ndo_sw_port_* - Functions that serve for a port-specific manipulation.

MAINTAINERS +7 -0

index 3a41fb0..776e078 100644
@@ -9003,6 +9003,13 @@ F:	lib/swiotlb.c
 F:	arch/*/kernel/pci-swiotlb.c
 F:	include/linux/swiotlb.h
+SWITCHDEV
+M:	Jiri Pirko <[email protected]>
+L:	[email protected]
+S:	Supported
+F:	net/switchdev/
+F:	include/net/switchdev.h
+
 SYNOPSYS ARC ARCHITECTURE
 M:	Vineet Gupta <[email protected]>
 S:	Supported

include/linux/netdevice.h +8 -0

index 71922e0..97eade9 100644
@@ -1017,6 +1017,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
  *	performing GSO on a packet. The device returns true if it is
  *	able to GSO the packet, false otherwise. If the return value is
  *	false the stack will do software GSO.
+ *
+ * int (*ndo_sw_parent_id_get)(struct net_device *dev,
+ *			       struct netdev_phys_item_id *psid);
+ *	Called to get an ID of the switch chip this port is part of.
+ *	If driver implements this, it indicates that it represents a port
+ *	of a switch chip.
  */
 struct net_device_ops {
 	int			(*ndo_init)(struct net_device *dev);

@@ -1168,6 +1174,10 @@ struct net_device_ops {
 	int			(*ndo_get_lock_subclass)(struct net_device *dev);
 	bool			(*ndo_gso_check) (struct sk_buff *skb,
 						  struct net_device *dev);
+#ifdef CONFIG_NET_SWITCHDEV
+	int			(*ndo_sw_parent_id_get)(struct net_device *dev,

include/linux/netdevice.h struct net_device_ops { · line 1179

Quoted 1 line

include/linux/netdevice.h +1 -0

+							struct netdev_phys_item_id *psid);

Can we keep the name generic and not include "sw" which implies switch here ?.
I understand that it is under CONFIG_NET_SWITCHDEV but we might find use for them in other offload scenarios in the future.
This particular ndo can be just ndo_parent_id_get().
And the others that do specific offloads can have "offload" in them if required..?.

Quoted 133 lines

include/linux/netdevice.h +1 -0

+#endif
 };
 /**

include/net/switchdev.h new file +30 -0

new file mode 100644
index 0000000..79bf9bd
@@ -0,0 +1,30 @@
+/*
+ * include/net/switchdev.h - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _LINUX_SWITCHDEV_H_
+#define _LINUX_SWITCHDEV_H_
+
+#include <linux/netdevice.h>
+
+#ifdef CONFIG_NET_SWITCHDEV
+
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid);
+
+#else
+
+static inline int netdev_sw_parent_id_get(struct net_device *dev,
+					  struct netdev_phys_item_id *psid)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif /* _LINUX_SWITCHDEV_H_ */

net/Kconfig +1 -0

index 99815b5..ff9ffc1 100644
@@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
 source "net/netlink/Kconfig"
 source "net/mpls/Kconfig"
 source "net/hsr/Kconfig"
+source "net/switchdev/Kconfig"
 config RPS
 	boolean

net/Makefile +3 -0

index 7ed1970..95fc694 100644
@@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH)	+= openvswitch/
 obj-$(CONFIG_VSOCKETS)	+= vmw_vsock/
 obj-$(CONFIG_NET_MPLS_GSO)	+= mpls/
 obj-$(CONFIG_HSR)		+= hsr/
+ifneq ($(CONFIG_NET_SWITCHDEV),)
+obj-y				+= switchdev/
+endif

net/switchdev/Kconfig new file +13 -0

new file mode 100644
index 0000000..1557545
@@ -0,0 +1,13 @@
+#
+# Configuration for Switch device support
+#
+
+config NET_SWITCHDEV
+	boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
+	depends on INET
+	---help---
+	  This module provides glue between core networking code and device
+	  drivers in order to support hardware switch chips in very generic
+	  meaning of the word "switch". This include devices supporting L2/L3 but
+	  also various flow offloading chips, including switches embedded into
+	  SR-IOV NICs.

net/switchdev/Makefile new file +5 -0

new file mode 100644
index 0000000..5ed63ed
@@ -0,0 +1,5 @@
+#
+# Makefile for the Switch device API
+#
+
+obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o

net/switchdev/switchdev.c new file +33 -0

new file mode 100644
index 0000000..5010f646
@@ -0,0 +1,33 @@
+/*
+ * net/switchdev/switchdev.c - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <net/switchdev.h>
+
+/**
+ *	netdev_sw_parent_id_get - Get ID of a switch
+ *	@dev: port device
+ *	@psid: switch ID
+ *
+ *	Get ID of a switch this port is part of.
+ */
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid)
+{
+	const struct net_device_ops *ops = dev->netdev_ops;
+
+	if (!ops->ndo_sw_parent_id_get)
+		return -EOPNOTSUPP;
+	return ops->ndo_sw_parent_id_get(dev, psid);
+}
+EXPORT_SYMBOL(netdev_sw_parent_id_get);

Quoted 131 lines · Wed, Nov 19, 2014 at 02:28:10PM CET, [email protected] wrote:

Quoted 130 lines · Jiri Pirko

The goal of this is to provide a possibility to support various switch chips. Drivers should implement relevant ndos to do so. Now there is only one ndo defined:
- for getting physical switch id is in place.

Note that user can use random port netdevice to access the switch.

Signed-off-by Jiri Pirko <[email protected]>

---
  Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
  MAINTAINERS                            |  7 ++++
  include/linux/netdevice.h              | 10 ++++++
  include/net/switchdev.h                | 30 +++++++++++++++++
  net/Kconfig                            |  1 +
  net/Makefile                           |  3 ++
  net/switchdev/Kconfig                  | 13 ++++++++
  net/switchdev/Makefile                 |  5 +++
  net/switchdev/switchdev.c              | 33 +++++++++++++++++++
  9 files changed, 161 insertions(+)

create mode 100644 Documentation/networking/switchdev.txt create mode 100644 include/net/switchdev.h create mode 100644 net/switchdev/Kconfig
create mode 100644 net/switchdev/Makefile
create mode 100644 net/switchdev/switchdev.c

Documentation/networking/switchdev.txt new file +59 -0

new file mode 100644
index 0000000..98be76c
@@ -0,0 +1,59 @@
+Switch (and switch-ish) device drivers HOWTO
+===========================
+
+Please note that the word "switch" is here used in very generic meaning.
+This include devices supporting L2/L3 but also various flow offloading chips,
+including switches embedded into SR-IOV NICs.
+
+Lets describe a topology a bit. Imagine the following example:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       port1 port2 port3 port4 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  NIC0 NIC1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+In this example, there are two independent lines between the switch silicon
+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
+separate from the switch driver. SOME switch chip is by managed by a driver
+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
+connected to some other type of bus.
+
+Now, for the previous example show the representation in kernel:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  eth0 eth1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
+created for each port of a switch. These netdevices are instances
+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
+of the switch chip. eth0 and eth1 are instances of some other existing driver.
+
+The only difference of the switch-port netdevice from the ordinary netdevice
+is that is implements couple more NDOs:
+
+	ndo_sw_parent_get_id - This returns the same ID for two port netdevices
+			       of the same physical switch chip. This is
+			       mandatory to be implemented by all switch drivers
+			       and serves the caller for recognition of a port
+			       netdevice.
+	ndo_sw_parent_* - Functions that serve for a manipulation of the switch
+			  chip itself (it can be though of as a "parent" of the
+			  port, therefore the name). They are not port-specific.
+			  Caller might use arbitrary port netdevice of the same
+			  switch and it will make no difference.
+	ndo_sw_port_* - Functions that serve for a port-specific manipulation.

MAINTAINERS +7 -0

index 3a41fb0..776e078 100644
@@ -9003,6 +9003,13 @@ F:	lib/swiotlb.c
  F:	arch/*/kernel/pci-swiotlb.c
  F:	include/linux/swiotlb.h
+SWITCHDEV
+M:	Jiri Pirko <[email protected]>
+L:	[email protected]
+S:	Supported
+F:	net/switchdev/
+F:	include/net/switchdev.h
+
  SYNOPSYS ARC ARCHITECTURE
  M:	Vineet Gupta <[email protected]>
  S:	Supported

include/linux/netdevice.h +8 -0

index 71922e0..97eade9 100644
@@ -1017,6 +1017,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
   *	performing GSO on a packet. The device returns true if it is
   *	able to GSO the packet, false otherwise. If the return value is
   *	false the stack will do software GSO.
+ *
+ * int (*ndo_sw_parent_id_get)(struct net_device *dev,
+ *			       struct netdev_phys_item_id *psid);
+ *	Called to get an ID of the switch chip this port is part of.
+ *	If driver implements this, it indicates that it represents a port
+ *	of a switch chip.
   */
  struct net_device_ops {
  	int			(*ndo_init)(struct net_device *dev);

@@ -1168,6 +1174,10 @@ struct net_device_ops {
  	int			(*ndo_get_lock_subclass)(struct net_device *dev);
  	bool			(*ndo_gso_check) (struct sk_buff *skb,
  						  struct net_device *dev);
+#ifdef CONFIG_NET_SWITCHDEV
+	int			(*ndo_sw_parent_id_get)(struct net_device *dev,

Quoted 8 lines

include/linux/netdevice.h struct net_device_ops { · line 1179

Quoted 1 line

include/linux/netdevice.h +1 -0

+							struct netdev_phys_item_id *psid);

Can we keep the name generic and not include "sw" which implies switch here ?.
I understand that it is under CONFIG_NET_SWITCHDEV but we might find use for them in other offload scenarios in the future.
This particular ndo can be just ndo_parent_id_get().
And the others that do specific offloads can have "offload" in them if required..?.

But this is for getting parent switch id, sw should be there.

If comes a
time when this might be reused to something else, we change it then. This is internal api, easily changeable.

Quoted 125 lines

Quoted 125 lines

include/linux/netdevice.h +1 -0

+#endif
  };
  /**

include/net/switchdev.h new file +30 -0

new file mode 100644
index 0000000..79bf9bd
@@ -0,0 +1,30 @@
+/*
+ * include/net/switchdev.h - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _LINUX_SWITCHDEV_H_
+#define _LINUX_SWITCHDEV_H_
+
+#include <linux/netdevice.h>
+
+#ifdef CONFIG_NET_SWITCHDEV
+
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid);
+
+#else
+
+static inline int netdev_sw_parent_id_get(struct net_device *dev,
+					  struct netdev_phys_item_id *psid)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif /* _LINUX_SWITCHDEV_H_ */

net/Kconfig +1 -0

index 99815b5..ff9ffc1 100644
@@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
  source "net/netlink/Kconfig"
  source "net/mpls/Kconfig"
  source "net/hsr/Kconfig"
+source "net/switchdev/Kconfig"
  config RPS
  	boolean

net/Makefile +3 -0

index 7ed1970..95fc694 100644
@@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH)	+= openvswitch/
  obj-$(CONFIG_VSOCKETS)	+= vmw_vsock/
  obj-$(CONFIG_NET_MPLS_GSO)	+= mpls/
  obj-$(CONFIG_HSR)		+= hsr/
+ifneq ($(CONFIG_NET_SWITCHDEV),)
+obj-y				+= switchdev/
+endif

net/switchdev/Kconfig new file +13 -0

new file mode 100644
index 0000000..1557545
@@ -0,0 +1,13 @@
+#
+# Configuration for Switch device support
+#
+
+config NET_SWITCHDEV
+	boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
+	depends on INET
+	---help---
+	  This module provides glue between core networking code and device
+	  drivers in order to support hardware switch chips in very generic
+	  meaning of the word "switch". This include devices supporting L2/L3 but
+	  also various flow offloading chips, including switches embedded into
+	  SR-IOV NICs.

net/switchdev/Makefile new file +5 -0

new file mode 100644
index 0000000..5ed63ed
@@ -0,0 +1,5 @@
+#
+# Makefile for the Switch device API
+#
+
+obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o

net/switchdev/switchdev.c new file +25 -0

new file mode 100644
index 0000000..5010f646
@@ -0,0 +1,33 @@
+/*
+ * net/switchdev/switchdev.c - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <net/switchdev.h>
+
+/**
+ *	netdev_sw_parent_id_get - Get ID of a switch
+ *	@dev: port device
+ *	@psid: switch ID
+ *
+ *	Get ID of a switch this port is part of.
+ */
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid)

Quoted 8 lines

net/switchdev/switchdev.c line 33

Quoted 8 lines

net/switchdev/switchdev.c new file +8 -0

+{
+	const struct net_device_ops *ops = dev->netdev_ops;
+
+	if (!ops->ndo_sw_parent_id_get)
+		return -EOPNOTSUPP;
+	return ops->ndo_sw_parent_id_get(dev, psid);
+}
+EXPORT_SYMBOL(netdev_sw_parent_id_get);

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 141 lines · Jiri Pirko

Quoted 131 lines · Wed, Nov 19, 2014 at 02:28:10PM CET, [email protected] wrote:

Quoted 130 lines · Jiri Pirko

The goal of this is to provide a possibility to support various switch chips. Drivers should implement relevant ndos to do so. Now there is only one ndo defined:
- for getting physical switch id is in place.

Note that user can use random port netdevice to access the switch.

Signed-off-by Jiri Pirko <[email protected]>

---
 Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
 MAINTAINERS                            |  7 ++++
 include/linux/netdevice.h              | 10 ++++++
 include/net/switchdev.h                | 30 +++++++++++++++++
 net/Kconfig                            |  1 +
 net/Makefile                           |  3 ++
 net/switchdev/Kconfig                  | 13 ++++++++
 net/switchdev/Makefile                 |  5 +++
 net/switchdev/switchdev.c              | 33 +++++++++++++++++++
 9 files changed, 161 insertions(+)
 create mode 100644 Documentation/networking/switchdev.txt
 create mode 100644 include/net/switchdev.h
 create mode 100644 net/switchdev/Kconfig
 create mode 100644 net/switchdev/Makefile
 create mode 100644 net/switchdev/switchdev.c

Documentation/networking/switchdev.txt new file +59 -0

new file mode 100644
index 0000000..98be76c
@@ -0,0 +1,59 @@
+Switch (and switch-ish) device drivers HOWTO
+===========================
+
+Please note that the word "switch" is here used in very generic meaning.
+This include devices supporting L2/L3 but also various flow offloading chips,
+including switches embedded into SR-IOV NICs.
+
+Lets describe a topology a bit. Imagine the following example:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       port1 port2 port3 port4 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  NIC0 NIC1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+In this example, there are two independent lines between the switch silicon
+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
+separate from the switch driver. SOME switch chip is by managed by a driver
+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
+connected to some other type of bus.
+
+Now, for the previous example show the representation in kernel:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  eth0 eth1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
+created for each port of a switch. These netdevices are instances
+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
+of the switch chip. eth0 and eth1 are instances of some other existing driver.
+
+The only difference of the switch-port netdevice from the ordinary netdevice
+is that is implements couple more NDOs:
+
+	ndo_sw_parent_get_id - This returns the same ID for two port netdevices
+			       of the same physical switch chip. This is
+			       mandatory to be implemented by all switch drivers
+			       and serves the caller for recognition of a port
+			       netdevice.
+	ndo_sw_parent_* - Functions that serve for a manipulation of the switch
+			  chip itself (it can be though of as a "parent" of the
+			  port, therefore the name). They are not port-specific.
+			  Caller might use arbitrary port netdevice of the same
+			  switch and it will make no difference.
+	ndo_sw_port_* - Functions that serve for a port-specific manipulation.

MAINTAINERS +7 -0

index 3a41fb0..776e078 100644
@@ -9003,6 +9003,13 @@ F:	lib/swiotlb.c
 F:	arch/*/kernel/pci-swiotlb.c
 F:	include/linux/swiotlb.h
+SWITCHDEV
+M:	Jiri Pirko <[email protected]>
+L:	[email protected]
+S:	Supported
+F:	net/switchdev/
+F:	include/net/switchdev.h
+
 SYNOPSYS ARC ARCHITECTURE
 M:	Vineet Gupta <[email protected]>
 S:	Supported

include/linux/netdevice.h +8 -0

index 71922e0..97eade9 100644
@@ -1017,6 +1017,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
  *	performing GSO on a packet. The device returns true if it is
  *	able to GSO the packet, false otherwise. If the return value is
  *	false the stack will do software GSO.
+ *
+ * int (*ndo_sw_parent_id_get)(struct net_device *dev,
+ *			       struct netdev_phys_item_id *psid);
+ *	Called to get an ID of the switch chip this port is part of.
+ *	If driver implements this, it indicates that it represents a port
+ *	of a switch chip.
  */
 struct net_device_ops {
 	int			(*ndo_init)(struct net_device *dev);

@@ -1168,6 +1174,10 @@ struct net_device_ops {
 	int			(*ndo_get_lock_subclass)(struct net_device *dev);
 	bool			(*ndo_gso_check) (struct sk_buff *skb,
 						  struct net_device *dev);
+#ifdef CONFIG_NET_SWITCHDEV
+	int			(*ndo_sw_parent_id_get)(struct net_device *dev,

Quoted 8 lines

include/linux/netdevice.h struct net_device_ops { · line 1179

Quoted 1 line

include/linux/netdevice.h +1 -0

+							struct netdev_phys_item_id *psid);

Can we keep the name generic and not include "sw" which implies switch here ?.
I understand that it is under CONFIG_NET_SWITCHDEV but we might find use for them in other offload scenarios in the future.
This particular ndo can be just ndo_parent_id_get().
And the others that do specific offloads can have "offload" in them if required..?.

Quoted 1 line

But this is for getting parent switch id, sw should be there.

Since we have not figured out the details or namespace for switchd ids yet, its still some parent id to me.

Quoted 3 lines

If comes a
time when this might be reused to something else, we change it then. This is internal api, easily changeable.

also, "sw" seems more "software" than "switch".

Quoted 138 lines

Quoted 126 lines

Quoted 126 lines

include/linux/netdevice.h +1 -0

+#endif
 };
 /**

include/net/switchdev.h new file +30 -0

new file mode 100644
index 0000000..79bf9bd
@@ -0,0 +1,30 @@
+/*
+ * include/net/switchdev.h - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _LINUX_SWITCHDEV_H_
+#define _LINUX_SWITCHDEV_H_
+
+#include <linux/netdevice.h>
+
+#ifdef CONFIG_NET_SWITCHDEV
+
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid);
+
+#else
+
+static inline int netdev_sw_parent_id_get(struct net_device *dev,
+					  struct netdev_phys_item_id *psid)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif /* _LINUX_SWITCHDEV_H_ */

net/Kconfig +1 -0

index 99815b5..ff9ffc1 100644
@@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
 source "net/netlink/Kconfig"
 source "net/mpls/Kconfig"
 source "net/hsr/Kconfig"
+source "net/switchdev/Kconfig"
 config RPS
 	boolean

net/Makefile +3 -0

index 7ed1970..95fc694 100644
@@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH)	+= openvswitch/
 obj-$(CONFIG_VSOCKETS)	+= vmw_vsock/
 obj-$(CONFIG_NET_MPLS_GSO)	+= mpls/
 obj-$(CONFIG_HSR)		+= hsr/
+ifneq ($(CONFIG_NET_SWITCHDEV),)
+obj-y				+= switchdev/
+endif

net/switchdev/Kconfig new file +13 -0

new file mode 100644
index 0000000..1557545
@@ -0,0 +1,13 @@
+#
+# Configuration for Switch device support
+#
+
+config NET_SWITCHDEV
+	boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
+	depends on INET
+	---help---
+	  This module provides glue between core networking code and device
+	  drivers in order to support hardware switch chips in very generic
+	  meaning of the word "switch". This include devices supporting L2/L3 but
+	  also various flow offloading chips, including switches embedded into
+	  SR-IOV NICs.

net/switchdev/Makefile new file +5 -0

new file mode 100644
index 0000000..5ed63ed
@@ -0,0 +1,5 @@
+#
+# Makefile for the Switch device API
+#
+
+obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o

net/switchdev/switchdev.c new file +25 -0

new file mode 100644
index 0000000..5010f646
@@ -0,0 +1,33 @@
+/*
+ * net/switchdev/switchdev.c - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <net/switchdev.h>
+
+/**
+ *	netdev_sw_parent_id_get - Get ID of a switch
+ *	@dev: port device
+ *	@psid: switch ID
+ *
+ *	Get ID of a switch this port is part of.
+ */
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid)

Quoted 8 lines

net/switchdev/switchdev.c line 33

Quoted 8 lines

net/switchdev/switchdev.c new file +8 -0

+{
+	const struct net_device_ops *ops = dev->netdev_ops;
+
+	if (!ops->ndo_sw_parent_id_get)
+		return -EOPNOTSUPP;
+	return ops->ndo_sw_parent_id_get(dev, psid);
+}
+EXPORT_SYMBOL(netdev_sw_parent_id_get);

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 150 lines · Roopa Prabhu

Quoted 141 lines · Jiri Pirko

Quoted 131 lines · Wed, Nov 19, 2014 at 02:28:10PM CET, [email protected] wrote:

Quoted 130 lines · Jiri Pirko

The goal of this is to provide a possibility to support various switch chips. Drivers should implement relevant ndos to do so. Now there is only one ndo defined:
- for getting physical switch id is in place.

Note that user can use random port netdevice to access the switch.

Signed-off-by Jiri Pirko <[email protected]>

---
 Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
 MAINTAINERS                            |  7 ++++
 include/linux/netdevice.h              | 10 ++++++
 include/net/switchdev.h                | 30 +++++++++++++++++
 net/Kconfig                            |  1 +
 net/Makefile                           |  3 ++
 net/switchdev/Kconfig                  | 13 ++++++++
 net/switchdev/Makefile                 |  5 +++
 net/switchdev/switchdev.c              | 33 +++++++++++++++++++
 9 files changed, 161 insertions(+)
 create mode 100644 Documentation/networking/switchdev.txt
 create mode 100644 include/net/switchdev.h
 create mode 100644 net/switchdev/Kconfig
 create mode 100644 net/switchdev/Makefile
 create mode 100644 net/switchdev/switchdev.c

Documentation/networking/switchdev.txt new file +59 -0

new file mode 100644
index 0000000..98be76c
@@ -0,0 +1,59 @@
+Switch (and switch-ish) device drivers HOWTO
+===========================
+
+Please note that the word "switch" is here used in very generic meaning.
+This include devices supporting L2/L3 but also various flow offloading chips,
+including switches embedded into SR-IOV NICs.
+
+Lets describe a topology a bit. Imagine the following example:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       port1 port2 port3 port4 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  NIC0 NIC1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+In this example, there are two independent lines between the switch silicon
+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
+separate from the switch driver. SOME switch chip is by managed by a driver
+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
+connected to some other type of bus.
+
+Now, for the previous example show the representation in kernel:
+
+       +----------------------------+    +---------------+
+       |     SOME switch chip       |    |      CPU      |
+       +----------------------------+    +---------------+
+       sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT    |     PCI-E     |
+         |     |     |     |     |       +---------------+
+        PHY   PHY    |     |     |         |  eth0 eth1
+                     |     |     |         |   |    |
+                     |     |     +- PCI-E -+   |    |
+                     |     +------- MII -------+    |
+                     +------------- MII ------------+
+
+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
+created for each port of a switch. These netdevices are instances
+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
+of the switch chip. eth0 and eth1 are instances of some other existing driver.
+
+The only difference of the switch-port netdevice from the ordinary netdevice
+is that is implements couple more NDOs:
+
+	ndo_sw_parent_get_id - This returns the same ID for two port netdevices
+			       of the same physical switch chip. This is
+			       mandatory to be implemented by all switch drivers
+			       and serves the caller for recognition of a port
+			       netdevice.
+	ndo_sw_parent_* - Functions that serve for a manipulation of the switch
+			  chip itself (it can be though of as a "parent" of the
+			  port, therefore the name). They are not port-specific.
+			  Caller might use arbitrary port netdevice of the same
+			  switch and it will make no difference.
+	ndo_sw_port_* - Functions that serve for a port-specific manipulation.

MAINTAINERS +7 -0

index 3a41fb0..776e078 100644
@@ -9003,6 +9003,13 @@ F:	lib/swiotlb.c
 F:	arch/*/kernel/pci-swiotlb.c
 F:	include/linux/swiotlb.h
+SWITCHDEV
+M:	Jiri Pirko <[email protected]>
+L:	[email protected]
+S:	Supported
+F:	net/switchdev/
+F:	include/net/switchdev.h
+
 SYNOPSYS ARC ARCHITECTURE
 M:	Vineet Gupta <[email protected]>
 S:	Supported

include/linux/netdevice.h +8 -0

index 71922e0..97eade9 100644
@@ -1017,6 +1017,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
  *	performing GSO on a packet. The device returns true if it is
  *	able to GSO the packet, false otherwise. If the return value is
  *	false the stack will do software GSO.
+ *
+ * int (*ndo_sw_parent_id_get)(struct net_device *dev,
+ *			       struct netdev_phys_item_id *psid);
+ *	Called to get an ID of the switch chip this port is part of.
+ *	If driver implements this, it indicates that it represents a port
+ *	of a switch chip.
  */
 struct net_device_ops {
 	int			(*ndo_init)(struct net_device *dev);

@@ -1168,6 +1174,10 @@ struct net_device_ops {
 	int			(*ndo_get_lock_subclass)(struct net_device *dev);
 	bool			(*ndo_gso_check) (struct sk_buff *skb,
 						  struct net_device *dev);
+#ifdef CONFIG_NET_SWITCHDEV
+	int			(*ndo_sw_parent_id_get)(struct net_device *dev,

Quoted 8 lines

include/linux/netdevice.h struct net_device_ops { · line 1179

Quoted 1 line

include/linux/netdevice.h +1 -0

+							struct netdev_phys_item_id *psid);

Can we keep the name generic and not include "sw" which implies switch here ?.
I understand that it is under CONFIG_NET_SWITCHDEV but we might find use for them in other offload scenarios in the future.
This particular ndo can be just ndo_parent_id_get().
And the others that do specific offloads can have "offload" in them if required..?.

Quoted 1 line

But this is for getting parent switch id, sw should be there.

Since we have not figured out the details or namespace for switchd ids yet, its still some parent id to me.

Quoted 3 lines

If comes a
time when this might be reused to something else, we change it then. This is internal api, easily changeable.

Quoted 1 line

also, "sw" seems more "software" than "switch".

I had voiced this same concern when we met and discussed this in Dusseldorf. Let's move to another name such as 'hw' (since we really are talking about hardware abstraction) or 'offload.' Just using 'sw' is confusing as many will not read it as switch.

I'll be happy to post a fix based on your devel patches.

Quoted 141 lines

Quoted 140 lines

Quoted 128 lines

Quoted 128 lines

include/linux/netdevice.h +1 -0

+#endif
 };
 /**

include/net/switchdev.h new file +30 -0

new file mode 100644
index 0000000..79bf9bd
@@ -0,0 +1,30 @@
+/*
+ * include/net/switchdev.h - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _LINUX_SWITCHDEV_H_
+#define _LINUX_SWITCHDEV_H_
+
+#include <linux/netdevice.h>
+
+#ifdef CONFIG_NET_SWITCHDEV
+
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid);
+
+#else
+
+static inline int netdev_sw_parent_id_get(struct net_device *dev,
+					  struct netdev_phys_item_id *psid)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif
+
+#endif /* _LINUX_SWITCHDEV_H_ */

net/Kconfig +1 -0

index 99815b5..ff9ffc1 100644
@@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
 source "net/netlink/Kconfig"
 source "net/mpls/Kconfig"
 source "net/hsr/Kconfig"
+source "net/switchdev/Kconfig"
 config RPS
 	boolean

net/Makefile +3 -0

index 7ed1970..95fc694 100644
@@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH)	+= openvswitch/
 obj-$(CONFIG_VSOCKETS)	+= vmw_vsock/
 obj-$(CONFIG_NET_MPLS_GSO)	+= mpls/
 obj-$(CONFIG_HSR)		+= hsr/
+ifneq ($(CONFIG_NET_SWITCHDEV),)
+obj-y				+= switchdev/
+endif

net/switchdev/Kconfig new file +13 -0

new file mode 100644
index 0000000..1557545
@@ -0,0 +1,13 @@
+#
+# Configuration for Switch device support
+#
+
+config NET_SWITCHDEV
+	boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
+	depends on INET
+	---help---
+	  This module provides glue between core networking code and device
+	  drivers in order to support hardware switch chips in very generic
+	  meaning of the word "switch". This include devices supporting L2/L3 but
+	  also various flow offloading chips, including switches embedded into
+	  SR-IOV NICs.

net/switchdev/Makefile new file +5 -0

new file mode 100644
index 0000000..5ed63ed
@@ -0,0 +1,5 @@
+#
+# Makefile for the Switch device API
+#
+
+obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o

net/switchdev/switchdev.c new file +25 -0

new file mode 100644
index 0000000..5010f646
@@ -0,0 +1,33 @@
+/*
+ * net/switchdev/switchdev.c - Switch device API
+ * Copyright (c) 2014 Jiri Pirko <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <net/switchdev.h>
+
+/**
+ *	netdev_sw_parent_id_get - Get ID of a switch
+ *	@dev: port device
+ *	@psid: switch ID
+ *
+ *	Get ID of a switch this port is part of.
+ */
+int netdev_sw_parent_id_get(struct net_device *dev,
+			    struct netdev_phys_item_id *psid)

Quoted 8 lines

net/switchdev/switchdev.c line 33

Quoted 8 lines

net/switchdev/switchdev.c new file +8 -0

+{
+	const struct net_device_ops *ops = dev->netdev_ops;
+
+	if (!ops->ndo_sw_parent_id_get)
+		return -EOPNOTSUPP;
+	return ops->ndo_sw_parent_id_get(dev, psid);
+}
+EXPORT_SYMBOL(netdev_sw_parent_id_get);

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---
  include/uapi/linux/if_link.h |  1 +
  net/core/rtnetlink.c         | 26 +++++++++++++++++++++++++-
  2 files changed, 26 insertions(+), 1 deletion(-)

include/uapi/linux/if_link.h +1 -0

index 7072d83..4163753 100644
@@ -145,6 +145,7 @@ enum {
  	IFLA_CARRIER,
  	IFLA_PHYS_PORT_ID,
  	IFLA_CARRIER_CHANGES,
+	IFLA_PHYS_SWITCH_ID,
  	__IFLA_MAX
  };
 

include/uapi/linux/if_link.h +0 -0

  static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {

Quoted 22 lines · Jiri Pirko

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---
 include/uapi/linux/if_link.h |  1 +
 net/core/rtnetlink.c         | 26 +++++++++++++++++++++++++-
 2 files changed, 26 insertions(+), 1 deletion(-)

include/uapi/linux/if_link.h +1 -0

index 7072d83..4163753 100644
@@ -145,6 +145,7 @@ enum {
 	IFLA_CARRIER,
 	IFLA_PHYS_PORT_ID,
 	IFLA_CARRIER_CHANGES,
+	IFLA_PHYS_SWITCH_ID,
 	__IFLA_MAX
 };
 

include/uapi/linux/if_link.h static const struct nla_policy ifla_policy[IFLA_MAX+1] = { · line 1226

Quoted 7 lines

include/uapi/linux/if_link.h +1 -0

@@ -1198,6 +1221,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
 	[IFLA_NUM_RX_QUEUES]	= { .type = NLA_U32 },
 	[IFLA_PHYS_PORT_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
 	[IFLA_CARRIER_CHANGES]	= { .type = NLA_U32 },  /* ignored */
+	[IFLA_PHYS_SWITCH_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
 };
 

Ok, looking at this compared to #1 i can see you are introducing IFLA_PHYS_SWITCH_ID but then why did you need to change IFLA_PHYS_PORT_ID earlier?

cheers,
jamal

Quoted 2 lines

include/uapi/linux/if_link.h +0 -0

 static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---
  include/uapi/linux/if_link.h |  1 +
  net/core/rtnetlink.c         | 26 +++++++++++++++++++++++++-
  2 files changed, 26 insertions(+), 1 deletion(-)

include/uapi/linux/if_link.h +0 -0

index 7072d83..4163753 100644

include/uapi/linux/if_link.h +0 -0

  	__IFLA_MAX
  };
 

net/core/rtnetlink.c +25 -1

index 1087c6d..f839354 100644
@@ -43,6 +43,7 @@
 
  #include <linux/inet.h>
  #include <linux/netdevice.h>
+#include <net/switchdev.h>
  #include <net/ip.h>
  #include <net/protocol.h>
  #include <net/arp.h>

@@ -868,7 +869,8 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
  	       + rtnl_port_size(dev, ext_filter_mask) /* IFLA_VF_PORTS + IFLA_PORT_SELF */
  	       + rtnl_link_get_size(dev) /* IFLA_LINKINFO */
  	       + rtnl_link_get_af_size(dev) /* IFLA_AF_SPEC */
-	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_PORT_ID */
+	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN) /* IFLA_PHYS_PORT_ID */
+	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_SWITCH_ID */
  }
 
  static int rtnl_vf_ports_fill(struct sk_buff *skb, struct net_device *dev)

@@ -967,6 +969,24 @@ static int rtnl_phys_port_id_fill(struct sk_buff *skb, struct net_device *dev)
  	return 0;
  }
 
+static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
+{
+	int err;
+	struct netdev_phys_item_id psid;
+
+	err = netdev_sw_parent_id_get(dev, &psid);
+	if (err) {
+		if (err == -EOPNOTSUPP)
+			return 0;
+		return err;
+	}
+
+	if (nla_put(skb, IFLA_PHYS_SWITCH_ID, psid.id_len, psid.id))
+		return -EMSGSIZE;
+
+	return 0;
+}
+
  static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
  			    int type, u32 pid, u32 seq, u32 change,
  			    unsigned int flags, u32 ext_filter_mask)

@@ -1039,6 +1059,9 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
  	if (rtnl_phys_port_id_fill(skb, dev))
  		goto nla_put_failure;
 
+	if (rtnl_phys_switch_id_fill(skb, dev))
+		goto nla_put_failure;
+
  	attr = nla_reserve(skb, IFLA_STATS,
  			sizeof(struct rtnl_link_stats));
  	if (attr == NULL)

@@ -1198,6 +1221,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
  	[IFLA_NUM_RX_QUEUES]	= { .type = NLA_U32 },
  	[IFLA_PHYS_PORT_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
  	[IFLA_CARRIER_CHANGES]	= { .type = NLA_U32 },  /* ignored */
+	[IFLA_PHYS_SWITCH_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
  };
 
  static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {

Quoted 16 lines · Jiri Pirko

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---
  include/uapi/linux/if_link.h |  1 +
  net/core/rtnetlink.c         | 26 +++++++++++++++++++++++++-
  2 files changed, 26 insertions(+), 1 deletion(-)

include/uapi/linux/if_link.h +0 -0

index 7072d83..4163753 100644

include/uapi/linux/if_link.h enum { · line 148

Quoted 4 lines

include/uapi/linux/if_link.h +1 -0

@@ -145,6 +145,7 @@ enum {
        IFLA_CARRIER,
        IFLA_PHYS_PORT_ID,
        IFLA_CARRIER_CHANGES,
+       IFLA_PHYS_SWITCH_ID,

Jiri, since we have not really converged on the switchdev class or having a separate switchdev instance,
am thinking it is better if we dont expose any such switch_id to userspace yet until absolutely needed. Do you need it today ?
There is no real in kernel hw switch driver that will use it today. And quite likely this will need to change when we introduce real hw switch drivers.

Quoted 21 lines · Roopa Prabhu

Quoted 15 lines · Jiri Pirko

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---
   include/uapi/linux/if_link.h |  1 +
   net/core/rtnetlink.c         | 26 +++++++++++++++++++++++++-
   2 files changed, 26 insertions(+), 1 deletion(-)

include/uapi/linux/if_link.h +0 -0

index 7072d83..4163753 100644

include/uapi/linux/if_link.h enum { · line 148

Quoted 4 lines

include/uapi/linux/if_link.h +1 -0

@@ -145,6 +145,7 @@ enum {
         IFLA_CARRIER,
         IFLA_PHYS_PORT_ID,
         IFLA_CARRIER_CHANGES,
+       IFLA_PHYS_SWITCH_ID,

Quoted 7 lines

Jiri, since we have not really converged on the switchdev class or having a separate switchdev instance,
am thinking it is better if we dont expose any such switch_id to userspace yet until absolutely needed. Do you need it today ?
There is no real in kernel hw switch driver that will use it today. And quite likely this will need to change when we introduce real hw switch drivers.

How will it change when real hw switch drivers are introduced? Will the real sw driver not be able to give a up unique ID for the switch?

Quoted 10 lines · Jiri Pirko

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---
 include/uapi/linux/if_link.h |  1 +
 net/core/rtnetlink.c         | 26 +++++++++++++++++++++++++-
 2 files changed, 26 insertions(+), 1 deletion(-)

include/uapi/linux/if_link.h enum { · line 148

Quoted 9 lines

include/uapi/linux/if_link.h +1 -0

index 7072d83..4163753 100644
@@ -145,6 +145,7 @@ enum {
 	IFLA_CARRIER,
 	IFLA_PHYS_PORT_ID,
 	IFLA_CARRIER_CHANGES,
+	IFLA_PHYS_SWITCH_ID,

Jiri, since we have not really converged on the switchdev class or having a separate switchdev instance,
am thinking it is better if we dont expose any such switch_id to userspace yet until absolutely needed. Do you need it today ?
There is no real in kernel hw switch driver that will use it today. And quite likely this will need to change when we introduce real hw switch drivers.

Quoted 64 lines

include/uapi/linux/if_link.h +0 -0

 	__IFLA_MAX
 };

net/core/rtnetlink.c +25 -1

index 1087c6d..f839354 100644
@@ -43,6 +43,7 @@
 #include <linux/inet.h>
 #include <linux/netdevice.h>
+#include <net/switchdev.h>
 #include <net/ip.h>
 #include <net/protocol.h>
 #include <net/arp.h>

@@ -868,7 +869,8 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
 	       + rtnl_port_size(dev, ext_filter_mask) /* IFLA_VF_PORTS + IFLA_PORT_SELF */
 	       + rtnl_link_get_size(dev) /* IFLA_LINKINFO */
 	       + rtnl_link_get_af_size(dev) /* IFLA_AF_SPEC */
-	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_PORT_ID */
+	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN) /* IFLA_PHYS_PORT_ID */
+	       + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_SWITCH_ID */
 }
 static int rtnl_vf_ports_fill(struct sk_buff *skb, struct net_device *dev)

@@ -967,6 +969,24 @@ static int rtnl_phys_port_id_fill(struct sk_buff *skb, struct net_device *dev)
 	return 0;
 }
+static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
+{
+	int err;
+	struct netdev_phys_item_id psid;
+
+	err = netdev_sw_parent_id_get(dev, &psid);
+	if (err) {
+		if (err == -EOPNOTSUPP)
+			return 0;
+		return err;
+	}
+
+	if (nla_put(skb, IFLA_PHYS_SWITCH_ID, psid.id_len, psid.id))
+		return -EMSGSIZE;
+
+	return 0;
+}
+
 static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
 			    int type, u32 pid, u32 seq, u32 change,
 			    unsigned int flags, u32 ext_filter_mask)

@@ -1039,6 +1059,9 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
 	if (rtnl_phys_port_id_fill(skb, dev))
 		goto nla_put_failure;
+	if (rtnl_phys_switch_id_fill(skb, dev))
+		goto nla_put_failure;
+
 	attr = nla_reserve(skb, IFLA_STATS,
 			sizeof(struct rtnl_link_stats));
 	if (attr == NULL)

@@ -1198,6 +1221,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
 	[IFLA_NUM_RX_QUEUES]	= { .type = NLA_U32 },
 	[IFLA_PHYS_PORT_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
 	[IFLA_CARRIER_CHANGES]	= { .type = NLA_U32 },  /* ignored */
+	[IFLA_PHYS_SWITCH_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
 };
 static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {

Quoted 11 lines · Mon, Nov 10, 2014 at 06:58:08PM CET, [email protected] wrote:

Quoted 10 lines · Jiri Pirko

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---
  include/uapi/linux/if_link.h |  1 +
  net/core/rtnetlink.c         | 26 +++++++++++++++++++++++++-
  2 files changed, 26 insertions(+), 1 deletion(-)

Quoted 16 lines

include/uapi/linux/if_link.h enum { · line 148

Quoted 9 lines

include/uapi/linux/if_link.h +1 -0

index 7072d83..4163753 100644
@@ -145,6 +145,7 @@ enum {
  	IFLA_CARRIER,
  	IFLA_PHYS_PORT_ID,
  	IFLA_CARRIER_CHANGES,
+	IFLA_PHYS_SWITCH_ID,

Jiri, since we have not really converged on the switchdev class or having a separate switchdev instance,
am thinking it is better if we dont expose any such switch_id to userspace yet until absolutely needed. Do you need it today ?
There is no real in kernel hw switch driver that will use it today. And quite likely this will need to change when we introduce real hw switch drivers.

When and if the switchdev class is introduced, switch id can happily live on. It is nothing against it. Userspace should use this id to group the ports of physical switch.

The netdevice represents a port in a switch, it will expose IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value belong to one physical switch.

Signed-off-by Jiri Pirko <[email protected]>

---

Signed-off-by Jiri Pirko <[email protected]>

---

This patch introduces the first driver to benefit from the switchdev infrastructure and to implement newly introduced switch ndos. This is a driver for emulated switch chip implemented in qemu:
https://github.com/sfeldma/qemu-rocker/

This patch is a result of joint work with Scott Feldman.

Signed-off-by Scott Feldman <[email protected]>

Signed-off-by Jiri Pirko <[email protected]>

---
  MAINTAINERS                          |    7 +
  drivers/net/ethernet/Kconfig         |    1 +
  drivers/net/ethernet/Makefile        |    1 +
  drivers/net/ethernet/rocker/Kconfig  |   27 +
  drivers/net/ethernet/rocker/Makefile |    5 +
  drivers/net/ethernet/rocker/rocker.c | 2060 ++++++++++++++++++++++++++++++++++
  drivers/net/ethernet/rocker/rocker.h |  427 +++++++
  7 files changed, 2528 insertions(+)

create mode 100644 drivers/net/ethernet/rocker/Kconfig create mode 100644 drivers/net/ethernet/rocker/Makefile create mode 100644 drivers/net/ethernet/rocker/rocker.c create mode 100644 drivers/net/ethernet/rocker/rocker.h

drivers/net/ethernet/rocker/rocker.c new file +23 -0

+			netdev_err(dev, "tx ring full when queue awake\n");
+		return NETDEV_TX_BUSY;
+	}
+
+	rocker_desc_cookie_ptr_set(desc_info, skb);
+
+	frags = rocker_tlv_nest_start(desc_info, ROCKER_TLV_TX_FRAGS);
+	if (!frags)
+		goto out;
+	err = rocker_tx_desc_frag_map_put(rocker_port, desc_info,
+					  skb->data, skb_headlen(skb));
+	if (err)
+		goto nest_cancel;
+	if (skb_shinfo(skb)->nr_frags > ROCKER_TX_FRAGS_MAX)
+		goto nest_cancel;
+
+	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+		const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+
+		err = rocker_tx_desc_frag_map_put(rocker_port, desc_info,
+						  skb_frag_address(frag),
+						  skb_frag_size(frag));
+		if (err)

drivers/net/ethernet/rocker/rocker.c new file +24 -0

+
+	return NETDEV_TX_OK;
+
+unmap_frags:
+	rocker_tx_desc_frags_unmap(rocker_port, desc_info);
+nest_cancel:
+	rocker_tlv_nest_cancel(desc_info, frags);
+out:
+	dev_kfree_skb(skb);
+	return NETDEV_TX_OK;
+}
+
+static int rocker_port_set_mac_address(struct net_device *dev, void *p)
+{
+	struct sockaddr *addr = p;
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	int err;
+
+	if (!is_valid_ether_addr(addr->sa_data))
+		return -EADDRNOTAVAIL;
+
+	err = rocker_cmd_set_port_settings_macaddr(rocker_port, addr->sa_data);
+	if (err)
+		return err;

drivers/net/ethernet/rocker/rocker.c new file +37 -0

+	psid->id_len = sizeof(rocker->hw.id);
+	memcpy(&psid->id, &rocker->hw.id, psid->id_len);
+	return 0;
+}
+
+static const struct net_device_ops rocker_port_netdev_ops = {
+	.ndo_open			= rocker_port_open,
+	.ndo_stop			= rocker_port_stop,
+	.ndo_start_xmit			= rocker_port_xmit,
+	.ndo_set_mac_address		= rocker_port_set_mac_address,
+	.ndo_sw_parent_id_get		= rocker_port_sw_parent_id_get,
+};
+
+/********************
+ * ethtool interface
+ ********************/
+
+static int rocker_port_get_settings(struct net_device *dev,
+				    struct ethtool_cmd *ecmd)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+
+	return rocker_cmd_get_port_settings_ethtool(rocker_port, ecmd);
+}
+
+static int rocker_port_set_settings(struct net_device *dev,
+				    struct ethtool_cmd *ecmd)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+
+	return rocker_cmd_set_port_settings_ethtool(rocker_port, ecmd);
+}
+
+static void rocker_port_get_drvinfo(struct net_device *dev,
+				    struct ethtool_drvinfo *drvinfo)
+{
+	strlcpy(drvinfo->driver, rocker_driver_name, sizeof(drvinfo->driver));

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 6 lines · Jiri Pirko

drivers/net/ethernet/rocker/rocker.c new file +6 -0

+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+					struct netdev_phys_item_id *psid)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address should work.

Quoted 11 lines · John Fastabend

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 6 lines · Jiri Pirko

drivers/net/ethernet/rocker/rocker.c new file +6 -0

+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+					struct netdev_phys_item_id *psid)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address should work.

This needs more work afterwards. Either we define that the switch ID is only unique in combination with the parent ifindex or we need to introduce a notation of uniquness into the switch ID itself.

Is the goal to expose a hardware ID here to allow identification of the hardware chip?

MAC is tempting but I'm pretty sure that we'll have pure L3 devices being handled by this API at some point.

Quoted 13 lines · Tue, Nov 11, 2014 at 03:29:46PM CET, [email protected] wrote:

Quoted 11 lines · John Fastabend

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 6 lines · Jiri Pirko

drivers/net/ethernet/rocker/rocker.c new file +6 -0

+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+					struct netdev_phys_item_id *psid)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address should work.

Quoted 3 lines

This needs more work afterwards. Either we define that the switch ID is only unique in combination with the parent ifindex or we need to introduce a notation of uniquness into the switch ID itself.

This is something similar to physical port id. Each driver should take care of generating that id.

Quoted 18 lines · Jiri Pirko

Quoted 16 lines · Tue, Nov 11, 2014 at 03:29:46PM CET, [email protected] wrote:

Quoted 11 lines · John Fastabend

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 6 lines · Jiri Pirko

drivers/net/ethernet/rocker/rocker.c new file +6 -0

+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+					struct netdev_phys_item_id *psid)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address should work.

This needs more work afterwards. Either we define that the switch ID is only unique in combination with the parent ifindex or we need to introduce a notation of uniquness into the switch ID itself.

Quoted 2 lines

This is something similar to physical port id. Each driver should take care of generating that id.

If the ID is only unique within a driver, then the user space cannot rely on using the ID to group switch ports. Multiple drivers might come up with the same ID.

Even now, multiple rocker instances would have the same ID.

Quoted 3 lines · Tue, Nov 11, 2014 at 04:32:32PM CET, [email protected] wrote:

If the ID is only unique within a driver, then the user space cannot rely on using the ID to group switch ports. Multiple drivers might come up with the same ID.

Well, as I said, it is the same as for physical port id. But if needed, there can be added some simple mechanism for the id registration ensuring their uniqueness.

Quoted 2 lines

Even now, multiple rocker instances would have the same ID.

It depends on what hw returns to driver.

Quoted 22 lines · Tue, Nov 11, 2014 at 04:32:32PM CET, [email protected] wrote:

Quoted 20 lines · Jiri Pirko

Quoted 13 lines · Tue, Nov 11, 2014 at 03:29:46PM CET, [email protected] wrote:

Quoted 11 lines · John Fastabend

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 6 lines · Jiri Pirko

drivers/net/ethernet/rocker/rocker.c new file +6 -0

+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+					struct netdev_phys_item_id *psid)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address should work.

Quoted 3 lines

This needs more work afterwards. Either we define that the switch ID is only unique in combination with the parent ifindex or we need to introduce a notation of uniquness into the switch ID itself.

This is something similar to physical port id. Each driver should take care of generating that id.

Quoted 3 lines

If the ID is only unique within a driver, then the user space cannot rely on using the ID to group switch ports. Multiple drivers might come up with the same ID.

Well, as I said, it is the same as for physical port id. But if needed, there can be added some simple mechanism for the id registration ensuring their uniqueness.

Quoted 3 lines

Even now, multiple rocker instances would have the same ID.

It depends on what hw returns to driver.

Quoted 15 lines · Jiri Pirko

Quoted 14 lines · Tue, Nov 11, 2014 at 03:29:46PM CET, [email protected] wrote:

Quoted 10 lines · John Fastabend

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 6 lines · Jiri Pirko

drivers/net/ethernet/rocker/rocker.c new file +6 -0

+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+					struct netdev_phys_item_id *psid)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address should work.

This needs more work afterwards. Either we define that the switch ID is only unique in combination with the parent ifindex or we need to introduce a notation of uniquness into the switch ID itself.

Quoted 2 lines

This is something similar to physical port id. Each driver should take care of generating that id.

If the ID is only unique within a driver, then the user space cannot rely on using the ID to group switch ports. Multiple drivers might come up with the same ID.

Even now, multiple rocker instances would have the same ID.

Quoted 19 lines · Thomas Graf

Quoted 18 lines · Jiri Pirko

Quoted 12 lines · Tue, Nov 11, 2014 at 03:29:46PM CET, [email protected] wrote:

Quoted 11 lines · John Fastabend

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 6 lines · Jiri Pirko

drivers/net/ethernet/rocker/rocker.c new file +6 -0

+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+                    struct netdev_phys_item_id *psid)
+{
+    struct rocker_port *rocker_port = netdev_priv(dev);
+    struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address
should work.

Quoted 3 lines

This needs more work afterwards. Either we define that the switch ID is only unique in combination with the parent ifindex or we need to introduce a notation of uniquness into the switch ID itself.

This is something similar to physical port id. Each driver should take care of generating that id.

Quoted 5 lines

If the ID is only unique within a driver, then the user space cannot rely on using the ID to group switch ports. Multiple drivers might come up with the same ID.

Even now, multiple rocker instances would have the same ID.

yep, that was my concern on the switch id namespace handling (on the other thread).

Quoted 23 lines · Jiri Pirko

This patch introduces the first driver to benefit from the switchdev infrastructure and to implement newly introduced switch ndos. This is a driver for emulated switch chip implemented in qemu:
https://github.com/sfeldma/qemu-rocker/

This patch is a result of joint work with Scott Feldman.

Signed-off-by Scott Feldman <[email protected]>

Signed-off-by Jiri Pirko <[email protected]>

---
 MAINTAINERS                          |    7 +
 drivers/net/ethernet/Kconfig         |    1 +
 drivers/net/ethernet/Makefile        |    1 +
 drivers/net/ethernet/rocker/Kconfig  |   27 +
 drivers/net/ethernet/rocker/Makefile |    5 +
 drivers/net/ethernet/rocker/rocker.c | 2060 ++++++++++++++++++++++++++++++++++
 drivers/net/ethernet/rocker/rocker.h |  427 +++++++
 7 files changed, 2528 insertions(+)
 create mode 100644 drivers/net/ethernet/rocker/Kconfig
 create mode 100644 drivers/net/ethernet/rocker/Makefile
 create mode 100644 drivers/net/ethernet/rocker/rocker.c
 create mode 100644 drivers/net/ethernet/rocker/rocker.h

[...]

Quoted 10 lines

drivers/net/ethernet/rocker/rocker.c new file +10 -0

+
+static netdev_tx_t rocker_port_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+	struct rocker_desc_info *desc_info;
+	struct rocker_tlv *frags;
+	int i;
+	int err;
+

drivers/net/ethernet/rocker/rocker.c line 1534

Quoted 3 lines

drivers/net/ethernet/rocker/rocker.c new file +3 -0

+	desc_info = rocker_desc_head_get(&rocker_port->tx_ring);
+	if (unlikely(!desc_info)) {
+		if (net_ratelimit())

Could you have a netif_stop_queue() here as well same as below? Not that optimizing the xmit routine is the interesting part of this patch. But I guess this is just some strange error path because I see you check this case below.

Quoted 24 lines

drivers/net/ethernet/rocker/rocker.c new file +23 -0

+			netdev_err(dev, "tx ring full when queue awake\n");
+		return NETDEV_TX_BUSY;
+	}
+
+	rocker_desc_cookie_ptr_set(desc_info, skb);
+
+	frags = rocker_tlv_nest_start(desc_info, ROCKER_TLV_TX_FRAGS);
+	if (!frags)
+		goto out;
+	err = rocker_tx_desc_frag_map_put(rocker_port, desc_info,
+					  skb->data, skb_headlen(skb));
+	if (err)
+		goto nest_cancel;
+	if (skb_shinfo(skb)->nr_frags > ROCKER_TX_FRAGS_MAX)
+		goto nest_cancel;
+
+	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+		const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+
+		err = rocker_tx_desc_frag_map_put(rocker_port, desc_info,
+						  skb_frag_address(frag),
+						  skb_frag_size(frag));
+		if (err)

drivers/net/ethernet/rocker/rocker.c line 1567

Quoted 10 lines

drivers/net/ethernet/rocker/rocker.c new file +10 -0

+			goto unmap_frags;
+	}
+	rocker_tlv_nest_end(desc_info, frags);
+
+	rocker_desc_gen_clear(desc_info);
+	rocker_desc_head_set(rocker, &rocker_port->tx_ring, desc_info);
+
+	desc_info = rocker_desc_head_get(&rocker_port->tx_ring);
+	if (!desc_info)
+		netif_stop_queue(dev);

I'm not entirely sure I followed the TLV usage here but OK. If it works...

Quoted 24 lines

drivers/net/ethernet/rocker/rocker.c new file +24 -0

+
+	return NETDEV_TX_OK;
+
+unmap_frags:
+	rocker_tx_desc_frags_unmap(rocker_port, desc_info);
+nest_cancel:
+	rocker_tlv_nest_cancel(desc_info, frags);
+out:
+	dev_kfree_skb(skb);
+	return NETDEV_TX_OK;
+}
+
+static int rocker_port_set_mac_address(struct net_device *dev, void *p)
+{
+	struct sockaddr *addr = p;
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	int err;
+
+	if (!is_valid_ether_addr(addr->sa_data))
+		return -EADDRNOTAVAIL;
+
+	err = rocker_cmd_set_port_settings_macaddr(rocker_port, addr->sa_data);
+	if (err)
+		return err;

drivers/net/ethernet/rocker/rocker.c line 1601

Quoted 10 lines

drivers/net/ethernet/rocker/rocker.c new file +10 -0

+	memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
+	return 0;
+}
+
+static int rocker_port_sw_parent_id_get(struct net_device *dev,
+					struct netdev_phys_item_id *psid)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+	struct rocker *rocker = rocker_port->rocker;
+

hmm looks like you read this out of a magic switch register :) but my switch doesn't have this magic reg. I suposse the switch MAC address should work.

Quoted 37 lines

drivers/net/ethernet/rocker/rocker.c new file +37 -0

+	psid->id_len = sizeof(rocker->hw.id);
+	memcpy(&psid->id, &rocker->hw.id, psid->id_len);
+	return 0;
+}
+
+static const struct net_device_ops rocker_port_netdev_ops = {
+	.ndo_open			= rocker_port_open,
+	.ndo_stop			= rocker_port_stop,
+	.ndo_start_xmit			= rocker_port_xmit,
+	.ndo_set_mac_address		= rocker_port_set_mac_address,
+	.ndo_sw_parent_id_get		= rocker_port_sw_parent_id_get,
+};
+
+/********************
+ * ethtool interface
+ ********************/
+
+static int rocker_port_get_settings(struct net_device *dev,
+				    struct ethtool_cmd *ecmd)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+
+	return rocker_cmd_get_port_settings_ethtool(rocker_port, ecmd);
+}
+
+static int rocker_port_set_settings(struct net_device *dev,
+				    struct ethtool_cmd *ecmd)
+{
+	struct rocker_port *rocker_port = netdev_priv(dev);
+
+	return rocker_cmd_set_port_settings_ethtool(rocker_port, ecmd);
+}
+
+static void rocker_port_get_drvinfo(struct net_device *dev,
+				    struct ethtool_drvinfo *drvinfo)
+{
+	strlcpy(drvinfo->driver, rocker_driver_name, sizeof(drvinfo->driver));

drivers/net/ethernet/rocker/rocker.c line 1648

Quoted 10 lines

drivers/net/ethernet/rocker/rocker.c new file +10 -0

+	strlcpy(drvinfo->version, UTS_RELEASE, sizeof(drvinfo->version));
+}
+
+static const struct ethtool_ops rocker_port_ethtool_ops = {
+	.get_settings		= rocker_port_get_settings,
+	.set_settings		= rocker_port_set_settings,
+	.get_drvinfo		= rocker_port_get_drvinfo,
+	.get_link		= ethtool_op_get_link,
+};
+

[...]

Looks reasonable to me, although I mostly scanned it and looked over the interface parts. My comments are just observations no need to change anything for them.

Reviewed-by John Fastabend <[email protected]>

Signature · 1 line

John Fastabend         Intel Corporation

From: Scott Feldman <[email protected]>

Add two new ndos: ndo_sw_port_fdb_add/del to offload static bridge fdb entries. Static bridge FDB entries are installed, for example, using iproute2 bridge cmd:

bridge fdb add ADDR dev DEV master vlan VID

This would install ADDR into the bridge's FDB for port DEV on vlan VID. The switch driver implements two ndo_swdev ops to add/delete FDB entries in the switch device:

int ndo_sw_port_fdb_add(struct net_device *dev,
const unsigned char *addr, u16 vid);

int ndo_sw_port_fdb_del(struct net_device *dev,
const unsigned char *addr, u16 vid);

The driver returns 0 on success, negative error code on failure.

Note: the switch driver would not implement ndo_fdb_add/del/dump on a port netdev as these are intended for devices maintaining their own FDB. In our case, we want the Linux bridge to own the FBD.

Note: by default, the bridge does not filter on VLAN and only bridges untagged traffic. To enable VLAN support, turn on VLAN filtering:

echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering

Quoted 26 lines · Jiri Pirko

From: Scott Feldman <[email protected]>

Add two new ndos: ndo_sw_port_fdb_add/del to offload static bridge fdb entries. Static bridge FDB entries are installed, for example, using iproute2 bridge cmd:

bridge fdb add ADDR dev DEV master vlan VID

This would install ADDR into the bridge's FDB for port DEV on vlan VID. The switch driver implements two ndo_swdev ops to add/delete FDB entries in the switch device:

int ndo_sw_port_fdb_add(struct net_device *dev,
const unsigned char *addr, u16 vid);

int ndo_sw_port_fdb_del(struct net_device *dev,
const unsigned char *addr, u16 vid);

The driver returns 0 on success, negative error code on failure.

Note: the switch driver would not implement ndo_fdb_add/del/dump on a port netdev as these are intended for devices maintaining their own FDB. In our case, we want the Linux bridge to own the FBD.

Quoted 5 lines

Note: by default, the bridge does not filter on VLAN and only bridges untagged traffic. To enable VLAN support, turn on VLAN filtering:

echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering

Sorry - why is the current fdb_add/del insufficient? It needs a vlanid and the master/self flags should indicate intent to add to h/w vs s/w.

cheers,
jamal

Quoted 27 lines · Mon, Nov 10, 2014 at 04:47:48AM CET, [email protected] wrote:

Quoted 26 lines · Jiri Pirko

From: Scott Feldman <[email protected]>

Add two new ndos: ndo_sw_port_fdb_add/del to offload static bridge fdb entries. Static bridge FDB entries are installed, for example, using iproute2 bridge cmd:

bridge fdb add ADDR dev DEV master vlan VID

This would install ADDR into the bridge's FDB for port DEV on vlan VID. The switch driver implements two ndo_swdev ops to add/delete FDB entries in the switch device:

int ndo_sw_port_fdb_add(struct net_device *dev,
const unsigned char *addr, u16 vid);

int ndo_sw_port_fdb_del(struct net_device *dev,
const unsigned char *addr, u16 vid);

The driver returns 0 on success, negative error code on failure.

Note: the switch driver would not implement ndo_fdb_add/del/dump on a port netdev as these are intended for devices maintaining their own FDB. In our case, we want the Linux bridge to own the FBD.

Quoted 8 lines

Quoted 5 lines

Note: by default, the bridge does not filter on VLAN and only bridges untagged traffic. To enable VLAN support, turn on VLAN filtering:

echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering

Sorry - why is the current fdb_add/del insufficient? It needs a vlanid and the master/self flags should indicate intent to add to h/w vs s/w.

Jamal, I believe we discussed this already. The thing is that current fdb_add/del does not need vlanid and master/self flags, because it already has that (struct nlattr *tb[]). Here is the whole list of parameters to these functions:
NDA_DST,
NDA_LLADDR,
NDA_CACHEINFO,
NDA_PROBES,
NDA_VLAN,
NDA_PORT,
NDA_VNI,
NDA_IFINDEX,
NDA_MASTER,

There are few problems in re-using this. It is netlink based so for calling it from bridge code, we would have to construct netlink message. But that could be probably changed.
As you can see from the list of parameters, this is no longer about fdb (addr, vlanid) but this has been extended to something else. See vxlan code for what this is used for. I believe that fdb_add/del should be renamed to something else, perhaps l2neigh_add/del or something like that. The other problem is that fdb_add/del is currently used by various drivers for different purpose (adding macs to unicast list).