Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration

From: Roopa Prabhu
Date: Thu Dec 11 2014 - 11:38:26 EST

On 12/11/14, 3:01 AM, Jiri Pirko wrote:
Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@xxxxxxxxx wrote:
-----Original Message-----
From: John Fastabend [mailto:john.fastabend@xxxxxxxxx]
Sent: Wednesday, December 10, 2014 5:04 PM
To: Jiri Pirko
Cc: Varlese, Marco; netdev@xxxxxxxxxxxxxxx;
stephen@xxxxxxxxxxxxxxxxxx; Fastabend, John R;
roopa@xxxxxxxxxxxxxxxxxxx; sfeldma@xxxxxxxxx; linux-
Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port

On 12/10/2014 08:50 AM, Jiri Pirko wrote:
Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@xxxxxxxxx wrote:
From: Marco Varlese <marco.varlese@xxxxxxxxx>

Switch hardware offers a list of attributes that are configurable on
a per port basis.
This patch provides a mechanism to configure switch ports by adding
an NDO for setting specific values to specific attributes.
There will be a separate patch that extends iproute2 to call the new

What are these attributes? Can you give some examples. I'm asking
because there is a plan to pass generic attributes to switch ports
replacing current specific ndo_switch_port_stp_update. In this case,
bridge is setting that attribute.

Is there need to set something directly from userspace or does it make
rather sense to use involved bridge/ovs/bond ? I think that both will
be needed.

I think for many attributes it would be best to have both. The in kernel callers
and netlink userspace can use the same driver ndo_ops.

But then we don't _require_ any specific bridge/ovs/etc module. And we
may have some attributes that are not specific to any existing software
module. I'm guessing Marco has some examples of these.


John Fastabend Intel Corporation
We do have a need to configure the attributes directly from user-space and I have identified the tool to do that in iproute2.

An example of attributes are:
* enabling/disabling of learning of source addresses on a given port (you can imagine the attribute called LEARNING for example);
* internal loopback control (i.e. LOOPBACK) which will control how the flow of traffic behaves from the switch fabric towards an egress port;
* flooding for broadcast/multicast/unicast type of packets (i.e. BFLOODING, MFLOODING, UFLOODING);

Some attributes would be of the type enabled/disabled while other will allow specific values to allow the user to configure different behaviours of that feature on that particular port on that platform.

One thing to mention - as John stated as well - there might be some attributes that are not specific to any software module but rather have to do with the actual hardware/platform to configure.

I hope this clarifies some points.
It does. Makes sense. We need to expose this attr set/get for both
in-kernel and userspace use cases.

Please adjust you patch for this. Also, as a second patch, it would be
great if you can convert ndo_switch_port_stp_update to this new ndo.

Why are we exposing generic switch attribute get/set from userspace ?. We already have specific attributes for learning/flooding which can be extended further.
And for in kernel api....i had a sample patch in my RFC series (Which i was going to resubmit, until it was decided that we will use existing api around ndo_bridge_setlink/ndo_bridge_getlink):


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at