netdev - Re: [net-next PATCH v2 02/12] net: flow

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:	Wed, 14 Jan 2015 06:55:05 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:	Thomas Graf <tgraf@...g.ch>, simon.horman@...ronome.com,
	Scott Feldman <sfeldma@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gerlitz.or@...il.com" <gerlitz.or@...il.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [net-next PATCH v2 02/12] net: flow_table: add flow, delete flow

On 01/13/2015 03:00 PM, Alexei Starovoitov wrote:
> On Tue, Jan 13, 2015 at 1:35 PM, John Fastabend
> <john.fastabend@...il.com> wrote:
>> Now that the device capabilities are exposed we can add support to
>> add and delete flows from the tables.
>>
>> The two operations are
>>
>> table_set_flows :
>>
>>    The set flow operations is used to program a set of flows into a
>>    hardware device table. The message is consumed via netlink encoded
>
> should now netlink cmd be called table_set_rules ?
> and s/flow/rule/ everywhere in commit log?
>
>>    message which is then decoded into a null terminated  array of
>>    flow entry structures. A flow entry structure is defined as
>>
>>       struct net_flow_flow {
>
> commit log no longer matches implementation ;)
> should be net_flow_rule ?
>

Oops, I guess I'll update it after waiting a bit for more feedback.

> can you update your .html writeup?

Took a quick scan at this think I caught most cases and some typos
as well.

> I hope to see more real examples in there.

Sure, I'll put together some more interesting examples in the next
day or so.

>
> btw how the whole thing will work with queue splitting from
> your other patch?
>

If one of the actions supported by the device is forward_to_queue() or
forward_to_socket() we can use the API to steer potentially interesting
packets to a user space application for processing.

Going the other way applications could tell the hardware to
drop/mangle/fwd packets. At some point I thought it would be interesting
to use both the the flow API here and the queue splitting from the
other patch with a tool like Suricata.

.John


-- 
John Fastabend         Intel Corporation
--
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