netdev - Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

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]

Message-ID: <5333150E.2010801@cumulusnetworks.com>
Date:	Wed, 26 Mar 2014 10:57:34 -0700
From:	Roopa Prabhu <roopa@...ulusnetworks.com>
To:	Florian Fainelli <f.fainelli@...il.com>
CC:	Jiri Pirko <jiri@...nulli.us>, Jamal Hadi Salim <jhs@...atatu.com>,
	Neil Horman <nhorman@...driver.com>,
	Thomas Graf <tgraf@...g.ch>, netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andy Gospodarek <andy@...yhouse.net>,
	dborkman <dborkman@...hat.com>, ogerlitz <ogerlitz@...lanox.com>,
	jesse <jesse@...ira.com>, pshelar <pshelar@...ira.com>,
	azhou <azhou@...ira.com>, Ben Hutchings <ben@...adent.org.uk>,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support
 of switch chip datapath

On 3/26/14, 10:29 AM, Florian Fainelli wrote:
> 2014-03-26 9:59 GMT-07:00 Jiri Pirko <jiri@...nulli.us>:
>> Wed, Mar 26, 2014 at 05:54:17PM CET, roopa@...ulusnetworks.com wrote:
>>> On 3/26/14, 3:54 AM, Jamal Hadi Salim wrote:
>>>> On 03/26/14 01:37, Roopa Prabhu wrote:
>>>>> On 3/25/14, 1:11 PM, Florian Fainelli wrote:
>>>>>> 2014-03-25 12:35 GMT-07:00 Neil Horman <nhorman@...driver.com>:
>>>>> Sorry about getting on this thread late and possibly in the middle.
>>>>> Agree on the idea of keeping the ports linked to the master switch dev
>>>>> (or the 'conduit' to the switch chip) via private list instead of the
>>>>> master-slave relationship proposed earlier.
>>>>> By private i mean the netdev->priv linkage to the master switch dev and
>>>>> not really keeping the ports from being exposed to the user.
>>>>>
>>>>> We think its better to keep the switch ports exposed as any other netdev
>>>>> on linux.
>>>>>   This approach will make the switch ports look exactly like a nic port
>>>>> and all tools will continue to work seamlessly. The switch port
>>>>> operations could internally be forwarded to the switch netdev (sw1 in
>>>>> the above case).
>>>>>
>>>>> example:
>>>>> $ip link set dev sw1p0 up
>>>>> $ethtool -S sw1p0
>>>>>
>>>> I like the approach. I know the above is a simple version, but i am
>>>> assuming you also mean i can do things like
>>>> ip route add ...
>>>> bridge fdb add ... (and if you like your brctl go ahead)
>>>> bonding ...
>>>>
>>> yes, exactly.  We support this model on our boxes today.
>>> User can bond switch ports on our box in the exact same way as he/she
>>> would bond two nic ports.
>>> Our 'conduit to switch chip' reflects the corresponding lag
>>> configuration in the switch chip.
>>> Same goes for bridging, routing, acls.
>>
>> So you implement bonding netlink api? Or you hook into bonding driver
>> itselt? Can you show us the code?
> Before we start talking about bonding, maybe we should make sure that
> we cover some basic hardware switches uses which are to make some
> ports belong to certain VLANs, tagged or untagged?
>
> It seems to me like this would become something like this, assuming P0
> and P1 are two switch ports and 'eth0' is the CPU port, where P0 and
> P1 belong to VLAN1 and CPU belongs to VLAN2:
>
> ip link set dev sw1p0 up
> ip link set dev sw1p1 up
> ip link set dev eth0 up
>
> ip link add link eth0 name eth0.2 type vlan id 2
>
> ip link add link sw1p0 name sw1p0.1 type vlan id 1
> ip link add link sw1p1 name sw1p1.1 type vlan id 1
>
> ip link add sw1.1 type bridge
> ip link set sw1p0.1 master sw1.1
> ip link set sw1p1.1 master sw1.1
>
> Does that fit the model correctly?
Not entirely, but close.
In our current model, there is no netdev for cpu port (or master switch 
netdev):

ip link set dev sw1p0 up
ip link set dev sw1p1 up

ip link add link sw1p0 name sw1p0.1 type vlan id 1
ip link add link sw1p1 name sw1p1.1 type vlan id 1

ip link add brvlan1 type bridge
ip link set swp1p0.1 master brvlan1
ip link set swp1p1.1 master brvlan1

switch driver programs the brvlan1 vlan in the switch asic.

bonding works in the same way.

Thanks,
Roopa


  



--
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