On Tue, Sep 2, 2014 at 6:55 PM, Jesse Gross <je...@nicira.com> 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. >
I agree it is good to integrate datapath with IPVS. I would like to see the design proposal. >> 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
