netdev - Re: [net-next PATCH v3 00/12] Flow API

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: <20150123160031.GL2065@nanopsycho.orion>
Date:	Fri, 23 Jan 2015 17:00:31 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	John Fastabend <john.fastabend@...il.com>,
	simon.horman@...ronome.com, sfeldma@...il.com,
	netdev@...r.kernel.org, davem@...emloft.net, gerlitz.or@...il.com,
	andy@...yhouse.net, ast@...mgrid.com
Subject: Re: [net-next PATCH v3 00/12] Flow API

Fri, Jan 23, 2015 at 04:49:49PM CET, tgraf@...g.ch wrote:
>On 01/23/15 at 04:25pm, Jiri Pirko wrote:
>> Fri, Jan 23, 2015 at 03:07:24PM CET, tgraf@...g.ch wrote:
>> >How does John's API fit into this? How would you expose capabilities
>> >through xflows? How would it differ from what John proposes?
>> 
>> This certainly need more thinking. The capabilities could be exposed
>> either by separate a genl api (like in this version) or directly via TC
>> netlink iface (RTM_GETTFILTERCAP, RTM_GETACTIONCAP). The insides of the
>> message can stay the same. I like the second way better.
>
>OK. Any particular reason why you like the tc integration better?

As I wrote earlier, that would provides us a single interface for flow
manipulation in both sw and hw. That is why I prefer tc here.


>
>> flow manipulation would happen as standard TC filters/actions manipulation.
>> Here, the Netlink messages could be also very similar to what John has now.
>
>I have one concern here: This would mean we put flow modifications
>under the rtnl lock which will have severe impact on the rate of
>flow modifications we can support. We need flow table modifications
>to continue being super fast.

I agree that is a problem. But I believe that can be resolved (have to
think about this some more).

>
>Parallel genetlink operations were introduced just for this.
>
>> Right. We have to either introduce some limitations for xflows to
>> disallow this or let the user to take care of this. But it's similar
>> problem as if you use tc with John's API or ovs with John's API.
>
>Agreed. It's a general problem with having multiple indepdent tools.
--
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