On Thu, Sep 23, 2021 at 9:02 AM Frode Nordahl <[email protected]>
wrote:
>
> 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).
>

Yes, hosting under ovn-org sounds good to me. We can discuss at OVN
meetings.

> 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