Date:	Fri, 21 Mar 2014 08:04:20 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Florian Fainelli <f.fainelli@...il.com>,
	Jiri Pirko <jiri@...nulli.us>
CC:	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

On 03/20/14 13:21, Florian Fainelli wrote:
> 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,
>>>

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

Ok, so that is what a bridge is.

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

Indeed. We have too many splinters already and each has its own way
of being addressed. [Did you know MacVLAN is now also a L2 device that
does bridging and a crap load of other things? A long way off from
what the original intent was.]

I think we are saying the same thing, but:
This means need for a consistent interface and abstraction.
My favorite abstraction in the kernel that i consider to be immortal
is the netdev. I can have a netdev that is implemented as a physical
ethernet port or as a tuntap or as a tunnel etc. They mostly use the
same abstraction with small differences depending on the type, f.e
a tuntap  with uid, gid etc is mostly no different than my laptop
realtek ethernet port. I can control any of those the same way I
control a CAN device on a vehicle with iproute2 and the same way i
control  a dummy device, ifb, veth, etc.
In otherwords, how packet processing happens (whether the netdev is
used to toast bread) or what tables or constructs a specific kind of
netdev needs (to slice bread) is only relevant to the implementation.
 From user space i dont need to have 15 different APIs to manage/control
things (ok, there is ethtool - but that is just one more interface; but
we have matured enough such that if you try to use /proc or /sysfs
people will yell at you).

In my view: that (immortal) device for L2/bridging is the bridge or
maybe a more barebone version of the bridge (since it has gained a
little more weight in recent times).

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

I had started documenting this stuff to provide some context for an
abstraction, but i had too many pre-emptions, so the document is not
complete. Both John and Vlad had provided inputs to shape it. I
could post it and take patches to it.

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

Your view is more detail oriented than mine. My focus is to more from
a control/management abstraction level. From that perspective this
is a healthy discussion - thank you.

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

I dont think so. I think we need to have this discussion to come
up with a reasonable conclusion.

cheers,
jamal
--
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