netdev - Re: [net-next PATCH v1 00/11] A 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] [day] [month] [year] [list]

Message-ID: <20150114190238.GB2105@casper.infradead.org>
Date:	Wed, 14 Jan 2015 19:02:38 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>, sfeldma@...il.com,
	jiri@...nulli.us, simon.horman@...ronome.com,
	netdev@...r.kernel.org, davem@...emloft.net, andy@...yhouse.net,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [net-next PATCH v1 00/11] A flow API

On 01/09/15 at 10:27am, John Fastabend wrote:
> Yes we are providing an interface for userspace to interrogate the
> hardware and program it. My take on this is even if you embed this
> into another netlink family OVS, NFT, TCA you end up with the same
> operations w.r.t. table support (a) query hardware for
> resources/constraints/etc and (b) an API to add/del rules in those
> tables. It seems the intersection of these features with existing
> netlink families is fairly small so I opted to create a new family.
> The underlying hardware offload mechanisms in flow_table.c here could
> be used by in-kernel consumers as well as user space. For some
> consumers 'tc' perhaps this makes good sense for others 'OVS'
> it does not IMO.

+1

> [...]
>
> But in many cases my goal is to unify them in userspace
> where it is easier to make policy decisions. For OVS, NFT it
> seems to me that user space libraries can handle the unification
> of hardware/software dataplanes. Further I think it is the correct
> place to unify the dataplanes. I don't want to encode complex
> policies into the kernel. Even if you embed the netlink UAPI into
> another netlink family the semantics look the same.

I think we want the kernel to remain in control but it does not
necessarily have to hold the offload decision logic for all users.
I think this is compareable to routing daemons. We do not want to
talk BPF or OSPF in the kernel and we don't need to know about all
of the selection logic behind it but we want to be in charge of
keeping track of the actual datapath routes.

Also, I think this is still an option to emebed the proposed
attribtues in existing Netlink families even if we shoot for a new
family for now. So far the attributes seem to be defined in a way
that would allow them to be embedded into other existing Netlink
families.

> Maybe I need to be enlightened but I thought for a bit about some grand
> unification of ovs, bridge, tc, netlink, et. al. but that seems like
> an entirely different scope of project. (side note: filters/actions
> are no longer locked by qdisc and could stand on their own) My thoughts
> on this are not yet organized.

I think everybody had this in the back of their mind at some point.
Be it based on BPF, NFT or TC. I don't think it's undoable but it
takes a lot of effort as each is based on a slightly different set
of assumptions with corresponding focus derived from that.
--
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