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: <20140326182943.GH22086@order.stressinduktion.org>
Date:	Wed, 26 Mar 2014 19:29:43 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	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 Wed, Mar 26, 2014 at 07:14:36PM +0100, Jiri Pirko wrote:
> >You are right, sw1p0 and sw1p1 were meant to be, say LAN ports in my example.
> >
> >I think there is an implicit convention that sw1 represents the
> >Ethernet switch port connected to the CPU Ethernet MAC, and that it is
> >always connected, hence there is no need to create a "fake" bridge to
> >link sw1 to eth0 for instance?
> 
> I think you are kind of mixing apples and oranges (or I might be I'm not
> understanding you correctly).

I guess the discussion is only about user interface:

In case someone adds a bond on switch ports without knowing the details
of the kernel and interfaces, the kernel would transparently setup this
configuration on the switch via the specific driver. iproute bond interface
stays the same but backend differs.

Actually, I find the idea pretty neat, but the bonding netlink/sysfs
interface would be required to expose feature information, because
maybe not every switch supports each (bonding) feature (like l4-hashing)
and software fallback maybe not possible.

> This is how I see it, sticking to the names you use in the example:
> 
>             (sw1) (abstract place-holder netdev)
>           --------
>          switch chip                   CPU
>    -----------------------            ------
>    sw1p0 sw1p1 sw1p2 sw1p3             eth0
>      |     |     |     |                |
>     PHY   PHY   PHY    ------someMII-----
> 
> You see that eth0 is the CPU part of the "connection" and sw1p3 is the
> switch part (port representation). 
>
> >>>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?

Why not make every switch a bridge (for the user POV) from the beginning
and send bridge netlink messages to switchdev then?

Greetings,

  Hannes

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