On Thu, Sep 23, 2021 at 12:53 AM Numan Siddique <[email protected]> wrote:
>
> On Tue, Sep 21, 2021 at 3:41 AM Han Zhou <[email protected]> wrote:
> >
> > On Fri, Sep 3, 2021 at 12:27 PM Frode Nordahl <[email protected]>
> > wrote:
> > >
> > > Add the first in-tree plug provider plugin and its dependencies.
> > > The representor plugin can be used with multiple NIC vendors
> > > supporting Open vSwitch hardware offload and the devlink-port
> > > infrastructure[0].
> > >
> > > It is particularly useful for use with NICs connected to multiple
> > > distinct CPUs where the instance runs on one host and Open
> > > vSwitch and OVN runs on a different host, the smartnic CPU.
> > >
> > > Extend the build system with macros from the OVS build system to
> > > allow checking for dependencies of the plugin as well as providing
> > > kernel header files that may not be available at build time.
> > >
> > > The plugin will only be built when enabled and when building on
> > > a Linux system.
> > >
> > > 0:
> > https://www.kernel.org/doc/html/latest/networking/devlink/devlink-port.html
> > > Signed-off-by: Frode Nordahl <[email protected]>
> > > ---
> > >  Documentation/automake.mk                     |   1 +
> > >  Documentation/topics/plug_providers/index.rst |   1 +
> > >  .../topics/plug_providers/plug-providers.rst  |   5 +
> > >  .../plug_providers/plug-representor.rst       |  45 ++
> > >  build-aux/initial-tab-whitelist               |   1 +
> > >  configure.ac                                  |   2 +
> > >  include/automake.mk                           |   4 +
> > >  include/linux/automake.mk                     |   2 +
> > >  include/linux/devlink.h                       | 625 ++++++++++++++++++
> > >  lib/automake.mk                               |  11 +
> > >  lib/plug-provider.h                           |   6 +-
> > >  lib/plug.c                                    |   1 +
> > >  .../representor/netlink-devlink.c             | 499 ++++++++++++++
> > >  .../representor/netlink-devlink.h             | 115 ++++
> > >  .../representor/plug-representor.c            | 307 +++++++++
> > >  m4/ovn.m4                                     |  26 +
> > >  16 files changed, 1650 insertions(+), 1 deletion(-)
> > >  create mode 100644
> > Documentation/topics/plug_providers/plug-representor.rst
> > >  create mode 100644 include/linux/automake.mk
> > >  create mode 100644 include/linux/devlink.h
> > >  create mode 100644 lib/plug_providers/representor/netlink-devlink.c
> > >  create mode 100644 lib/plug_providers/representor/netlink-devlink.h
> > >  create mode 100644 lib/plug_providers/representor/plug-representor.c
> > >
> >
> > Hi Frode,
> >
> > Thanks for adding this to the series. This does provide a better
> > understanding of how the plug_provider interfaces are going to be used for
> > representor ports. However, I had no idea how complex this provider would
> > be when I proposed adding it to the repo. Now that I am seeing it, I am not
> > sure if it is a good idea. It is probably better to maintain this provider
> > under a separate project, primarily because of totally different focus and
> > dependencies. For an in-tree provider, I'd consider something that plugs
> > regular VIFs.
> >
> > I'd also like to hear what other maintainers think. I am sorry for not
> > realizing this earlier, and if we finally decide to exclude this single
> > patch from the series, I hope this doesn't waste too much of your effort,
> > assuming the majority of the code would be the same when it is hosted under
> > a separate repo.
> >
>
> I'd agree with Han.  It is better if this implementation is out of the
> tree.  +1 from me
> if you think this can be an ovn-org github project.

That's fair and when I think about it, in line with what we have
discussed in previous RFC reviews so I'll leave this patch out of the
set going into core OVN.

I have already done the build system work for building with an
external plug provider as well as started staging a repository that
should be suitable for upstreaming once it is complete. Having it
hosted on github.com/ovn-org would be sufficient for our needs of
being able to refer to API documentation in an official place for use
in ongoing work in other projects.

Would it work for you to discuss how to go about it in next Thursday's
meeting for example? (I have to skip this evenings meeting
unfortunately).

Cheers!

-- 
Frode Nordahl

> Thanks
> Numan
>
> > Thanks,
> > Han
> > _______________________________________________
> > dev mailing list
> > [email protected]
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to