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:	Wed, 04 Mar 2015 17:54:54 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	David Christensen <davidch@...adcom.com>
CC:	Tom Herbert <therbert@...gle.com>,
	Simon Horman <simon.horman@...ronome.com>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [ovs-dev] OVS Offload Decision Proposal

On 03/04/2015 04:04 PM, David Christensen wrote:
>>> 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

I think a set operation _is_ necessary for OVS and other applications
that run in user space. The more I work with this the clearer it is
that this is needed for a class of applications/controllers that want
to work on a richer set of the pipeline for optimization reasons. For
example OVS doesn't want to query/set on a single table of the pipeline
but possibly multiple tables and it needs to know the layout. Now
if you want to make that set operation look like a 'tc' command or 'nft'
command I think we can debate that. Although I'm in favour of keeping
the existing flow api with the 'set' command for the class of
applications that want to use it. The set operation as it exists now
is ideal for the hardware case 'nft' will require a translation step.
'tc' is actually a bit closer IMO but I'm not sure 'tc' applications
want to work on optimizing hardware tables.

We need to support both models, both the kernel consumer and the user
space consumer.

What was wrong with the initial set which I've subsequently resolved is
it needs to be constrained a bit to only allow well-defined actions and
well-defined matches. Also the core module needs to manage the hardware
resource and ensure it is managed correctly so that multiple consumers
do not stomp on eachother.

I've CC'd Pablo.

Thanks,
.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