Date:   Fri, 30 Sep 2016 15:12:58 -0700
From:   pravin shelar <pshelar@....org>
To:     Simon Horman <simon.horman@...ronome.com>
Cc:     Or Gerlitz <gerlitz.or@...il.com>,
        "dev@...nvswitch.org" <dev@...nvswitch.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Rony Efraim <ronye@...lanox.com>
Subject: Re: [ovs-dev] [PATCH/RFC 00/12] Programming Open vSwitch (-like)
 flows into hardware using SwitchDev

On Thu, Sep 29, 2016 at 1:09 AM, Simon Horman
<simon.horman@...ronome.com> wrote:
> Hi Or,
>
> On Wed, Sep 28, 2016 at 04:54:40PM +0300, Or Gerlitz wrote:
>> On Wed, Sep 28, 2016 at 3:42 PM, Simon Horman
>> <simon.horman@...ronome.com> wrote:
>>
>> > A different approach, not implemented by this patch-set, is for user-space
>> > to program flows into hardware by some other means, for example TC, and/or
>> > the (kernel) datapath.
>>
>> Right, and we've submitted that code to the OVS community 24h ago [1].
>>
>> This was done along the feedback we've got for the last two years (since
>> the  LPC 2014 networking micro-conf). It allows offloading from
>> multiple user-space
>> applications through a single UAPI -- the TC one (currently we did
>> flower, but the OVSD
>> patch set can be extended to use whatever TC offloads are supported by
>> the port driver,
>> e.g U32, eBPF) and integration with 3rd party policy modules  running
>> in user-space.
>>
>> Lets hear people opinions and see where we go from now.
>>
>> > I believe that approach does not conflict with this one.
>> >  And there is some scope to share infrastructure in the kernel
>>
>> maybe, possibly
>>
>> We've having a talk in netdev 1.2 on offloading HW offloading of OVS
>> and similar applications,
>> I would encourage people to come and approach me and/or Rony Efraim
>> from Mellanox before/after
>> the talk to discuss that F2F, would love to get feedbacks, and also here...
>
> Thanks for putting my post in context with the work you mention.
> I am looking forward to some F2F discussions next week.
>

I will not be able to come to netdev conference, so I wanted to post
my thoughts here.
I would like to thank for sharing the code. But I see some issues with
this design for flow offloading.

1. This adds OVS specific flow based offloading piece to switchdev
rather than adding generic one. Any switchdev flow based offloads
would be available to OVS only. Any other software switch can not make
use of it.
2. This complicates OVS kernel module by adding hardware related state
in datapath. OVS datapath is suppose to be software switch.
3. Since this switchdev offload is controlled by OVS kernel module,
any new API exposed by switchdev would need some changes to OVS kernel
module and possibly OVS API.
4. There is project going on to rewrite OVS kernel module in eBPF.
Thus plugging in hardware offload in the OVS kernel module make it
obsolete once we move to new implementation. We would need to rewrite
hardware offload again for eBPF OVS.
5. OVS kernel module has much less context than userspace. So
userspace based API can use the context and can be more effective when
offloading a flow to limited offloading resources.
6. This patch has also increased struct flow size but most of users
would not be using switchdev offloads.
7. This could be a just a bug, but patch 11 changes OVS_FLOW_CMD_SET
API where flow key has changed a required parameter from optional.

Why not allow switchdev offload API for userspace similar to TC flower
offload? or we could use flower API for switchdev flow offload.

Thanks,
Pravin.

Powered by blists - more mailing lists