[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A2D8AE08A@IRVEXCHMB11.corp.ad.broadcom.com>
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
Powered by blists - more mailing lists