Date:	Tue, 31 Mar 2015 19:15:35 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	Jiri Pirko <jiri@...nulli.us>, Scott Feldman <sfeldma@...il.com>,
	Netdev <netdev@...r.kernel.org>
CC:	roopa <roopa@...ulusnetworks.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Florian Fainelli <f.fainelli@...il.com>
Subject: RE: [PATCH net-next 11/18] switchdev: remove old
 netdev_switch_port_bridge_setlink



>-----Original Message-----
>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.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@...el.com wrote:
>>
>>
>>>-----Original Message-----
>>>From: Scott Feldman [mailto:sfeldma@...il.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 <ronen.arad@...el.com> wrote:
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
>On
>>>>>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 <roopa@...ulusnetworks.com> wrote:
>>>>>> On 3/30/15, 1:40 AM, sfeldma@...il.com wrote:
>>>>>>>
>>>>>>> From: Scott Feldman <sfeldma@...il.com>
>>>>>>>
>>>>>>> New attr-based bridge_setlink can recurse lower devs and recover on
>err,
>>>>>>> so
>>>>>>> remove old wrapper.  Also, restore br_setlink back to original and
>don't
>>>>>>> call
>>>>>>> into SELF port driver.  rtnetlink.c:bridge_setlink already does a call
>>>>>>> into
>>>>>>> port driver for SELF.
>>>>>>>
>>>>>>> Signed-off-by: Scott Feldman <sfeldma@...il.com>
>>>>>>
>>>>>> removing this now requires every vlan add to be a two step process, why
>?
>>>>>
>>>>>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
>>>>>
>>>>>
>>>>>> 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


>>
>>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@...r.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists