netdev - Re: [PATCH] net: phy: b53: switchdev driver for Broadcom BCM53xx switches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Feb 2015 10:26:32 -0800
From:	Scott Feldman <sfeldma@...il.com>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	Rafał Miłecki <zajec5@...il.com>,
	Andrew Lunn <andrew@...n.ch>,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	Jonas Gorski <jogo@...nwrt.org>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	Felix Fietkau <nbd@...nwrt.org>, Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH] net: phy: b53: switchdev driver for Broadcom BCM53xx switches

On Thu, Feb 26, 2015 at 9:58 AM, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 26/02/15 07:49, Rafał Miłecki wrote:
>> On 26 February 2015 at 16:36, Andrew Lunn <andrew@...n.ch> wrote:
>>>> It doesn't really answer my question as I don't see functionality I'm
>>>> looking for in bcm_sf2. I don't see it handling (un)tagging or PVID
>>>> anywhere. It makes me believe such features are not implemented (and
>>>> not configurable) using bridges/dsa at all. Can you any API related to
>>>> untagging / PVID?
>>>
>>> The (un)tagging code is in net/dsa/tag_brcm.c This is generic code, so
>>> you would not expect to find it in bcm_sf2. All you need to do is set
>>>
>>>         .tag_protocol           = DSA_TAG_PROTO_BRCM,
>>>
>>> in your dsa_switch_driver structure and the core DSA code will ensure
>>> the packets gets the header applied/removed.
>>
>> Sorry, I wasn't clear enough. I don't mean Broadcom proto tagging, but
>> a 802.1Q VLAN header including e.g. VID.
>>
>> I'd like to have control over VLAN ID ports are using. The hardware
>> allows me to define VLAN with a number and also if:
>> 1) Packets incoming on port X should be modified (by hw) to include
>> 802.11Q header
>> 2) Packets leaving port Y should be stripped out of 802.11Q header or not
>>
>> Above allows me to create some fun setups. For example I can configure
>> my Linux interface to send packets with VID N. Then I can tell
>> hardware to:
>> 1) Send packets with VID N untagged to port 1
>> 2) Send packets with VID N still tagged to port 2
>>
>> I don't see any way to achieve that with dsa. On the other hand this
>> is what my proposed b53 driver allows. I could achieve above setup
>> using:
>> bridge vlan add vid N dev sw0p1 pvid untagged
>> bridge vlan add vid N dev sw0p2
>> bridge vlan add vid N dev sw0p8
>>
>
> What we are currently missing today in DSA, which is on my TODO list as
> well, is to add support for precisely this, using the existing:
>
> ndo_add_vlan_rx_add_vid, ndo_vlan_rx_kill_vid, ndo_bridge_getlink and
> ndo_bridge_setlink. Essentialy the same thing same your driver does,
> just one level above, at the DSA layer, so we can have all DSA drivers
> advertise/report that feature.

Yes, with rocker we also used ndo_add_vlan_rx_add_vid,
ndo_vlan_rx_kill_vid to figure out the VLAN assignments on a bridge
port, and it works great.  What we haven't got to yet (on our TODO
list) is get access to the PVID of the bridge and use that for the
internal VLAN ID of the chip rather than reserving a portion of the
VLAN space for internal VLAN IDs.  You can use ndo_bridge_getlink and
ndo_bridge_setlink to get same VLAN info, but I think
ndo_add_vlan_rx_add_vid, ndo_vlan_rx_kill_vid is a better choice
because those will also work for the non-bridged port that is assigned
a VLAN, using vconfig for example.
--
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