On Tue, Sep 02, 2014 at 06:55:14PM -0700, Jesse Gross wrote: > On Mon, Sep 1, 2014 at 1:10 AM, Simon Horman <simon.hor...@netronome.com> > wrote: > > On Thu, Aug 28, 2014 at 10:12:49AM +0900, Simon Horman wrote: > >> On Wed, Aug 27, 2014 at 03:03:53PM -0500, Jesse Gross wrote: > >> > On Wed, Aug 27, 2014 at 11:51 AM, Ben Pfaff <b...@nicira.com> wrote: > >> > > On Wed, Aug 27, 2014 at 10:26:14AM +0900, Simon Horman wrote: > >> > >> On Fri, Aug 22, 2014 at 08:30:08AM -0700, Ben Pfaff wrote: > >> > >> > On Fri, Aug 22, 2014 at 09:19:41PM +0900, Simon Horman wrote: > >> > >> What we would like to do is to provide something generally useful > >> > >> which may be used as appropriate to: > >> > > > >> > > I'm going to skip past these ideas, which do sound interesting, because > >> > > I think that they're more for Pravin and Jesse than for me. I hope > >> > > that > >> > > they will provide some reactions to them. > >> > > >> > For the hardware offloading piece in particular, I would take a look > >> > at the discussion that has been going on in the netdev mailing list. I > >> > think the general consensus (to the extent that there is one) is that > >> > the hardware offload interface should be a block outside of OVS and > >> > then OVS (mostly likely from userspace) configures it. > >> > >> Thanks, I am now digesting that conversation. > > > > A lively conversation indeed. > > > > We are left with two questions for you: > > > > 1. Would you look at a proposal (I have some rough code that even works) > > for a select group action in the datapath prior to the finalisation > > of the question of offloads infrastructure in the kernel? > > > > From our point of view we would ultimately like to use such an action to > > offload to hardware. But it seems that there might be use-cases (not the > > one that I have rough code for) where such an action may be useful. For > > example to allow parts of IPVS to be used to provide stateful load > > balancing. > > > > Put another: It doesn't seem that a select group action is dependent on > > an offloads tough there are cases where they could be used together. > > I agree that this is orthogonal to offloading and seems fine to do > now. It seems particularly nice if we can use IPVS in a clean way, > similar to what is currently being worked on for connection tracking. > > I guess I'm not entirely sure how you plan to offload this to hardware > so it's hard to say how it would intersect in the future. However, the > current plan is to have offloading be directed for a higher point > (i.e. userspace) and have the OVS kernel module remain a software path > so probably it doesn't really matter. > > However, I'll Pravin comment since he'll be the one reviewing the code.
Thanks, I will respond to this separately as a response to Pravin's email. > > 2. Would you consider an set of offload-hooks for Open vSwitch at this time? > > > > These could be backed by loading a module that implements the relevant > > hooks. And in the longer term one such module (possibly to rule them > > all) could be implemented using the kernel offload API that has > > been the subject of recent lively discussion. > > I'm not too excited about doing an interim offloading API for this, > especially since I think the long term version is likely to be > significantly different. Thanks, that answers my question. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
