netdev - RE: [ovs-dev] OVS Offload Decision Proposal

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, 5 Mar 2015 00:04:15 +0000
From:	David Christensen <davidch@...adcom.com>
To:	Tom Herbert <therbert@...gle.com>,
	Simon Horman <simon.horman@...ronome.com>
CC:	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: RE: [ovs-dev] OVS Offload Decision Proposal

> > That said, my working assumptions are:
> >
> > * That Open vSwitch may manage flow offloads from user-space. This is as
> >   opposed to them being transparently handled in the datapath. This does
> >   not preclude the existence of transparent offloading in the datapath.
> >   But rather limits this discussion to a mode where offloads are managed
> >   from user-space.
> >
> > * That Open vSwitch may add flows to hardware via an API provided by the
> >   kernel. In particular my working assumption is that the Flow API
> proposed
> >   by John Fastabend[3] may be used to add flows to hardware. While the
> >   existing netlink API may be used to add flows to the kernel datapath.
> >
> Doesn't this imply two entities to be independently managing the same
> physical resource? If so, this raises questions of how the resource
> would be partitioned between them? How are conflicting requests
> between the two rectified?

The consensus at Netdev was that "set" operations would be removed from
flow API to limit hardware management to the kernel only.  Existing "get"
operations would remain so user space is aware of the device capabilities.

Dave