[ovs-dev] [PATCH v12 00/11] Add offload support for sFlow

[Simon Horman]

On Tue, May 18, 2021 at 02:22:26PM +0200, Ilya Maximets wrote:
> On 4/27/21 3:23 AM, Chris Mi wrote:

...

> > Hi Ilya,
> > 
> > The code according to your suggestion is ready. But during the internal
> > code review, Eli Britstein thought flow_api is netdev based, but the
> > psample/sFlow offload is not netdev based, but dpif based. Maybe we
> > should introduce dpif-offload-provider and have a dpf_offload_api, so
> > it won't be related to a specific netdev, but to a dpif type.
> > 
> > Could I know what's your opinion about it?
> 
> This might be not bad idea in general.  The problem is that if we'll
> introduce this kind of API, we'll need to remove the usage of
> netdev-offload API from all the layers higher than dpif implementation
> including dpif.c and make all offloading go through
> dpif-offload-provider.
> 
> In general, I think, it might be good to have a separate dpif type, e.g.
> dpif-offload that will use netdev-offload APIs internally and provide
> offloading service.  In this case, dpif_operate(), depending on offload
> configuration, will try to install flows to dpif-offload first and
> fallback to install flows to the main dpif implementation if offload
> failed or if it was partial (i.e.  classification offloading).  This way
> we will delete all the offloading related code from dpif-netdev and
> dpif-netlink and will have a unified offloading architecture.  It's not
> easy to implement and there will be a lot of issues that we'll need to
> figure out how to fix (e.g. dpif-netdev performs upcalls by itself, so it
> will have to install resulted flows by calling a dpif_flow_put/operate
> and not install flows directly to its local flow tables).  Anyway, this
> looks like a long run and will require rework of the whole offloading
> architecture, so might be a separate thing to work on.  Thoughts?

Hi Ilya, Hi Chris,

I think that this approach makes sense in terms of an evolution of
the internal offload APIs/architecture. And might lean itself to more
advanced options in future - such as layered dpif implementations for
some purpose.

I do also there will be quite a lot of implementation challenges
to overcome.

Kind regards,
Simon