netdev - Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload

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: <53FB3D5E.6090200@mojatatu.com>
Date:	Mon, 25 Aug 2014 09:42:54 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Scott Feldman <sfeldma@...ulusnetworks.com>
CC:	Thomas Graf <tgraf@...g.ch>,
	John Fastabend <john.fastabend@...il.com>,
	Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	dborkman <dborkman@...hat.com>, ogerlitz <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, f.fainelli@...il.com,
	roopa@...ulusnetworks.com, linville@...driver.com,
	dev@...nvswitch.org, jasowang@...hat.com, ebiederm@...ssion.com,
	nicolas.dichtel@...nd.com, ryazanov.s.a@...il.com,
	buytenh@...tstofly.org, aviadr@...lanox.com, nbd@...nwrt.org,
	alexei.starovoitov@...il.com, Neil.Jerram@...aswitch.com,
	ronye@...lanox.com
Subject: Re: [patch net-next RFC 10/12] openvswitch: add support for datapath
 hardware offload

On 08/24/14 22:24, Scott Feldman wrote:
>
> On Aug 24, 2014, at 8:15 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
>

>
> With respect to focus on L2/L3, I have a pretty *good* hunch someone could
 > write a kernel module that gleans from the L2/L3 netlink echoes 
already flying
>around and translates to sw_flows and in turn into ndo_swdev_flow_* calls.

And herein lies the fundamental disagreement.
I dont believe the flow interface is appropriate for either L2/3.
We already have some L2 interfaces (they are incomplete if you want
to capture everything a large switch does).
L3 should go the same path.

And as i said earlier, i dont think the flow interface
is appropriate as a universal classifier interface either.
You need to allow for different types of classifiers. You
need to allow for a mix and match of classifiers (although
the later could be evolutionary).

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