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