Re: [ovs-dev] [PATCH/RFC 00/12] Programming Open vSwitch (-like) flows into hardware using SwitchDev
On Sat, Oct 1, 2016 at 1:12 AM, pravin shelar wrote: [...] > Why not allow switchdev offload API for userspace similar to TC flower > offload? or we could use flower API for switchdev flow offload. Hi Pravin, Could you also share your thoughts on the RFC we've posted couple of days ago to the OVS devel mailing list? the offloading there [1] is from OVSD using TC/Flower Or. [1] http://openvswitch.org/pipermail/dev/2016-September/079952.html ___ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
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 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 >> 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. ___ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC 00/12] Programming Open vSwitch (-like) flows into hardware using SwitchDev
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 > 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. > Or. > > [1] pointers to patches implementing the 2nd approach > > cover-letter http://openvswitch.org/pipermail/dev/2016-September/079952.html > > patches > > https://patchwork.ozlabs.org/patch/675560/ > https://patchwork.ozlabs.org/patch/675567/ > https://patchwork.ozlabs.org/patch/675565/ > https://patchwork.ozlabs.org/patch/675559/ > https://patchwork.ozlabs.org/patch/675564/ > https://patchwork.ozlabs.org/patch/675563/ > https://patchwork.ozlabs.org/patch/675568/ > https://patchwork.ozlabs.org/patch/675566/ > https://patchwork.ozlabs.org/patch/675562/ > > [2] http://www.netdevconf.org/1.2/session.html?rony-efraim-1 ___ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH/RFC 00/12] Programming Open vSwitch (-like) flows into hardware using SwitchDev
On Wed, Sep 28, 2016 at 3:42 PM, Simon Horman 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... Or. [1] pointers to patches implementing the 2nd approach cover-letter http://openvswitch.org/pipermail/dev/2016-September/079952.html patches https://patchwork.ozlabs.org/patch/675560/ https://patchwork.ozlabs.org/patch/675567/ https://patchwork.ozlabs.org/patch/675565/ https://patchwork.ozlabs.org/patch/675559/ https://patchwork.ozlabs.org/patch/675564/ https://patchwork.ozlabs.org/patch/675563/ https://patchwork.ozlabs.org/patch/675568/ https://patchwork.ozlabs.org/patch/675566/ https://patchwork.ozlabs.org/patch/675562/ [2] http://www.netdevconf.org/1.2/session.html?rony-efraim-1 ___ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
