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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
