-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
Behalf Of Jiri Pirko
Sent: Monday, March 30, 2015 10:53 PM
To: Arad, Ronen
Cc: Scott Feldman; Netdev; roopa; Guenter Roeck; Florian Fainelli
Subject: Re: [PATCH net-next 11/18] switchdev: remove old
netdev_switch_port_bridge_setlink

Tue, Mar 31, 2015 at 02:08:34AM CEST, ronen.arad@intel.com wrote:

quoted

quoted

-----Original Message-----
From: Scott Feldman [mailto:sfeldma@gmail.com]
Sent: Monday, March 30, 2015 2:28 PM
To: Arad, Ronen
Cc: roopa; Netdev; Jirí Pírko; Guenter Roeck; Florian Fainelli
Subject: Re: [PATCH net-next 11/18] switchdev: remove old
netdev_switch_port_bridge_setlink

On Mon, Mar 30, 2015 at 1:46 PM, Arad, Ronen [off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]

On

quoted

quoted

quoted

quoted

Behalf Of Scott Feldman
Sent: Monday, March 30, 2015 1:20 PM
To: roopa
Cc: Netdev; Jiří Pírko; Guenter Roeck; Florian Fainelli
Subject: Re: [PATCH net-next 11/18] switchdev: remove old
netdev_switch_port_bridge_setlink

On Mon, Mar 30, 2015 at 6:23 AM, roopa [off-list ref] wrote:

quoted

On 3/30/15, 1:40 AM, sfeldma@gmail.com wrote:

quoted

From: Scott Feldman <redacted>

New attr-based bridge_setlink can recurse lower devs and recover on

err,

quoted

quoted

quoted

quoted

quoted

quoted

so
remove old wrapper.  Also, restore br_setlink back to original and

don't

quoted

quoted

quoted

quoted

quoted

quoted

call
into SELF port driver.  rtnetlink.c:bridge_setlink already does a call
into
port driver for SELF.

Signed-off-by: Scott Feldman <redacted>

removing this now requires every vlan add to be a two step process, why

?

quoted

quoted

quoted

quoted

No, that's not true.  You want to use
ndo_vlan_rx_add_vid/ndo_vlan_rx_kill_vid in your port driver, and then
using either vlan driver standalone or the bridge driver vlan support
will work.

Try it.  Implement ndo_vlan_rx_add_vid in your port driver and verify
you get called to add VLAN to port with either:

   bridge vlan add dev swp1 vid 10

   -or-

   vconfig add swp1 10

Same for deleting a VLAN, either of these two commands call into the
port driver ndo_vlan_rx_kill_vid:

   bridge vlan del dev swp1 vid 10

   -or-

   vconfig rem swp1 10

quoted

bridge vlan add dev swp1 vid 10
bridge vlan add dev swp1 vid 10 self

Not necessary.  The first command is sufficient if using
ndo_vlan_rx_add_vid.

This is not sufficient for VLAN filtering. Ndo_vlan_rx_add_vid does not
provide the vinfo flags PVID and UNTAGGED. Therefore it is not
an adequate replacement for propagating setlink/dellink messages to the
swithport driver or an alternative via swdev_attr.

Glad you bring that point up.  I think these can get cast as port
attrs and set using swdev_attr.  This is something swdev attr should
open up is allowing more settings to be pushed down to port driver.
I'll look into this one and include it with v2.

It could be beneficial to build extensibility into swdev_attr.
An experimenter attribute designed to carry arbitrary data could allow
for passing new attributes and implementation specific attributes
without affecting any existing switchdev driver:

Warning sign...

I believe that we don't want this. It is very easy to add attribute for
anything. Having this "universal attribuute" only allows wild things...

Thanks.

Jiri

Let's say a switch device has some behavior that is not common to all
switch devices. Defining an explicit attribute might not be desirable
in that case. For example let's say SOMEswitch device implements VLAN
priority markdown using a table. It could be represented as a table of
8 bytes. To support this feature, there is a need to allow a user-space
tool to program such table in SOMEswitch device. What mechanisms are 
available for that?
This could be done via sysfs entries. However, I believe we're trying
to make Netlink and iproute2 the protocol/tool for all switch device
configuration. Therefore, I think that a generic mechanism, integrated
with existing switchdev supported tools would be best. 
Alternative approach would be for SOMEswitch driver to introduce its
own generic netlink family and introduce SOMEswitch version of iproute2
or similar tool to augment SOMEswitch HW configuration where (or as long
as) no common way to control such feature is available

quoted

enum swdev_attr_id {
	SWDEV_ATTR_UNDEFINED,
SWDEV_ATTR_EXPERIMENTER,
	SWDEV_ATTR_PORT_PARENT_ID,
SWDEV_ATTR_PORT_STP_STATE,
};


struct swdev_experimenter_attr {
u32 exp_id; 	/* - MSB 0: low-order bytes are IEEE OUI */
		/* - MSB != 0: reserved for netdev */
u32 exp_attr;
u16 exp_attr_size;
const void *exp_attr_data;
}

struct swdev_attr {
enum swdev_attr_id attr;
u32 flags;

	union {
		struct netdev_phys_item_id ppid;	/* PORT_PARENT_ID */
		u8 stp_state;				/* PORT_STP_STATE */
	unsigned long brport_flags;	/* PORT_BRIDGE_FLAGS */
	/* netdev defined attributes abobe this line */
	struct swdev_experimenter_attr exp_attr;
	};

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