[ovs-dev] [RFC] Proposal for enhanced select groups

[Pravin Shelar]

On Tue, Sep 2, 2014 at 6:55 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Mon, Sep 1, 2014 at 1:10 AM, Simon Horman <simon.horman at 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 <blp at 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.