[ovs-dev] [PATCH ovn v3 1/7] ovn-sb: Add plugged_by column to Port_Binding.
Han Zhou
hzhou at ovn.org
Sat Aug 28 00:13:10 UTC 2021
On Wed, Aug 25, 2021 at 11:00 PM Frode Nordahl <frode.nordahl at canonical.com>
wrote:
> > > +
> > > + <column name="options" key="plug-type">
> > > + If set, OVN will attempt to to perform plugging of this
VIF. In
> > > + order to get this port plugged by the OVN controller,
OVN must be
> > > + built with support for VIF plugging. The default
behavior is for
> > > + the CMS to do the VIF plugging.
> > > + Supported values: representor
> > > + </column>
> > > +
> > > + <column name="options" key="plug-pf-mac">
> > > + MAC address for identifying PF device. When
> > > + <ref column="options" key="plug-vf-num"/> is also set,
this
> > > + option is used to identify PF to use as base to locate
the correct
> > > + VF representor port. When
> > > + <ref column="options" key="plug-vf-num"/> is not set this
> > > + option is used to locate a PF representor port.
> > > + </column>
> > > +
> > > + <column name="options" key="plug-vf-num">
> > > + Logical VF number relative to PF device specified in
> > > + <ref column="options" key="plug-pf-mac"/>.
> > > + </column>
> > > +
> > > + <column name="options" key="plug-mtu-request">
> > > + Requested MTU for plugged interfaces. When set the OVN
controller
> > > + will fill the <ref table="Interface"
column="mtu_request"/> column
> > > + of the Open vSwitch database's
> > > + <ref table="Interface" db="vswitch"/> table. This in
turn will
> > > + make OVS vswitchd update the MTU of the linked interface.
> > > + </column>
> >
> > For the above 3 options, they are used only for plug-type
"representor", right? So it is better to have a naming convention that for
each type, the options should have a prefix: "plug:<plug type>:<option name
for the plug type>", e.g. "plug:representor:pf-mac".
>
> The additional namespacing you are proposing does make sense to me,
> will add. Thx!
>
Hi Frode, sorry I forgot to mention that for the provider-specific options,
it may be better to add the documentation together with the provider
implementation. I think it makes sense to add commonly used provider code
to the ovn repo, such as the representor one you already developed, maybe
under a new folder lib/plug_providers/. In this patch, it is better just
describe the generic part of the plug-type and the rules of the
plug-provider options, instead of adding real ones. What do you think?
More information about the dev
mailing list