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: <CAGVrzcbqQGGYb2Wkkekei7ivGd2XOnE+5GthLUv6_nD_oicrSQ@mail.gmail.com>
Date:	Thu, 20 Mar 2014 10:21:10 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>, andy@...yhouse.net,
	tgraf@...g.ch, dborkman@...hat.com, ogerlitz@...lanox.com,
	jesse@...ira.com, pshelar@...ira.com, 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>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of
 switch chip datapath

2014-03-20 5:40 GMT-07:00 Jiri Pirko <jiri@...nulli.us>:
> Thu, Mar 20, 2014 at 12:49:07PM CET, jhs@...atatu.com wrote:
>>Hi Jiri,
>>
>>On 03/19/14 11:33, Jiri Pirko wrote:
>>>This is just an early draft, RFC. I wanted to post this early to get the
>>>feedback as soon as possible.
>>>
>>>The basic idea is to introduce a generic infractructure to support various
>>>switch chips in kernel. Also the idea is to benefit of currently existing
>>>Open vSwitch userspace infrastructure.
>>>
>>
>>
>>I think the abstraction should be a netdev and to be specific the
>>bridge - not openvswitch. Our current tools like ifconfig, iproute2,
>>bridge etc should continue to work.
>
> That is exactly the case. Nothing is specific to OVS. OVS is just a one
> method to access the switchdev api.
>
> Abstraction is netdev. One netdev per each switch port and one netdev as
> a master on the top of that representing the switch itself.
>
>
>>In my experience, it is sufficient to model a switch after the linux
>>bridge at the basic level if the starting point is
>>L2 (which is the lowest common denominator).
>>And then you add capabilities that different chips expose.
>>Not every chip can do vxlan, flows etc. And we already know how
>>to abstract those out.
>>My  experience on top of broadcom chips is the approach i described
>>works rather well.
>>
>>Additionally, note:
>>We do have L2 devices that offload in the kernel
>>(refer to DSA, posting earlier from the openwrt guys, and
>>the intel devices which do VDMQ etc). I am now counting we have 5
>>different approaches if we add yours.
>
> I think that the problem is that each solution serves different purpose.
> For example DSA is for switches connected as a PHY to a MAC. That is
> completely different case to what my switchdev API is trying to handle.

I agree with Jamal here, we should try to find a solution that fits
most users here, it seems to me like there are 3 switches categories:

- entreprise built-in switches in NICs that support VF/PF
- embedded/entreprise switches that support tagging (Marvell eDSA/DSA,
Broadcom tags)
- embedded switches that only support 802.1q VLANs

The first category is more flow-oriented than control-oriented,
whereas the last two are more "event and control" oriented where you
usually have a system where the switch will be configured not to flood
the CPU port if possible, but when it does, this is to perform
specific configuration (address learning, port protection, snooping,
authorization...).

DSA is not designed specifically for switches which are connected to a
MAC and appear as a regular PHY, this is how it first started, but
nothing prevents you from using DSA with a switch that is e.g: memory
mapped into your CPU register space, MDIO is just the transport for
the control part.

For instance, if my switches support a N-bytes tag that will give me a
reason code for receiving this frame, and a bitmap representing the
originating port, how would you imagine this fitting into the
openvswitch/switchdev model, aside from the netdev per-port? Do you
think we could easily migrate existing DSA users to
openvswitch/switchdev by handling the custom switch tag?
-- 
Florian
--
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