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]

Date:	Thu, 20 Mar 2014 07:49:07 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
CC:	davem@...emloft.net, 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@...adent.org.uk, stephen@...workplumber.org,
	jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
	xiyou.wangcong@...il.com, john.r.fastabend@...el.com,
	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

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

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