Re: [ovs-dev] [PATCH ovn v4 8/9] binding: Consider plugging of ports on CMS request.
On Fri, Sep 17, 2021 at 9:22 PM Numan Siddique wrote: > > On Fri, Sep 17, 2021 at 12:41 PM Frode Nordahl > wrote: > > > > On Fri, Sep 17, 2021 at 1:16 AM Numan Siddique wrote: > > > > > > On Fri, Sep 3, 2021 at 3:28 PM Frode Nordahl > > > wrote: > > > > > > > > When OVN is linked with an appropriate plugging implementation, > > > > CMS can request OVN to plug individual lports into the local > > > > Open vSwitch instance. > > > > > > > > The port and instance record will be maintained during the lifetime > > > > of the lport and it will be removed on release of lport. > > > > > > > > Signed-off-by: Frode Nordahl > > > > > > Hi Frode, > > > > > > I've a few comments with the approach taken in this patch. > > > This patch calls the plug_port APIs from binding.c. This complicates > > > the already complicated binding.c code and I think plug_port() related > > > stuff > > > can be handled separately. I don't see a need for binding.c to be aware > > > of > > > plugging feature. For binding.c to claim a port, the ovs interface should > > > have external_ids:iface-id set to the port binding lport_name. > > > > > > Below is how I would see this can be done: > > > > > > 1. Add a new file called - controller/plug.c which will handle port > > > binding > > > changes - plug_handle_port_binding_changes (and possibly ovs > > > port/ovs interface changes). > > > > > > 2. The function plug_handle_port_binding_changes() will iterate through > > > the > > > tracked port bindings and if the port binding has the required > > > options set > > > (i.e requested-chassis and plug-type) it will call plug_port APIs and > > > create > > > or delete OVS ports. This function can access the lbinding data > > > stored in the runtime data. > > > > > > 3. For recompute scenarios, there can be a function - plug_run() which > > > will > > > iterate through all the port bindings and create/delete ovs ports. > > > > > > 4. When the OVS ports are created / deleted in (2), in the next run, > > > the binding module > > > will claim or release the port binding. binding.c module > > > wouldn't need to care > > > if the port binding / ovs port is created by the plug module or > > > by some other > > > mechanism. > > > > > > 5. The functions plug_handle_port_binding_changes() can be either called > > > by > > > runtime_data_sb_port_binding_handler() (i.e runtime engine node) > > > or another engine node for plug handling can be created which will > > > handle > > > port binding changes (and possibly ovs port/interface changes). > > > Similarly for full recompute, either runtime_data_run() can call > > > plug_run() > > > or a new engine run function can call it. Having a separate engine > > > node > > > seems better but then it needs to have runtime data as input > > > to access the lbinding information. > > > > > > 6. If you think plug.c should handle ovs port/interface changes, then > > > you > > > can add handlers for it too. > > > > > > > > > What do you think ? Would this proposal work ? Let me know if > > > something is not clear > > > and I can try to explain better. > > > > Numan, thank you so much for the review and for providing such a > > detailed and complete counter proposal, this is most appreciated. > > > > > I agree with you completely and have started working on such an approach. > > Great. Thanks. > > > > This does mean I will most likely miss the 21.09 release with this > > series, which is unfortunate for me, but that's ok. Better to get it > > into a great shape for the next one than taking risks or cutting > > corners for this one. > > If the patches look good before the official release, then I've no objection > to backporting to the newly created branch. Great. I'll have something up for review tomorrow or early next week, and we'll see where we get to. Thanks! -- Frode Nordahl > Thanks > Numan > > > > > Cheers! > > > > -- > > Frode Nordahl > > > > > Thanks > > > Numan > > > > > > > --- > > > > controller/binding.c| 247 ++-- > > > > tests/ovn-controller.at | 31 + > > > > tests/ovn-macros.at | 2 +- > > > > 3 files changed, 272 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/controller/binding.c b/controller/binding.c > > > > index 938e1d81d..ae67ee3fc 100644 > > > > --- a/controller/binding.c > > > > +++ b/controller/binding.c > > > > @@ -35,7 +35,9 @@ > > > > #include "local_data.h" > > > > #include "lport.h" > > > > #include "ovn-controller.h" > > > > +#include "ovsport.h" > > > > #include "patch.h" > > > > +#include "plug.h" > > > > > > > > VLOG_DEFINE_THIS_MODULE(binding); > > > > > > > > @@ -45,6 +47,8 @@ VLOG_DEFINE_THIS_MODULE(binding); > > > > */ > > > > #define OVN_INSTALLED_EXT_ID "ovn-installed" > > > > > > > > +#define OVN_PLUGGED_EXT_ID "ovn-plugged" > > > > + > > > > #define OVN_QOS_TYPE "linux-htb" > > > > > > >
Re: [ovs-dev] [PATCH ovn v4 8/9] binding: Consider plugging of ports on CMS request.
On Fri, Sep 17, 2021 at 12:41 PM Frode Nordahl
wrote:
>
> On Fri, Sep 17, 2021 at 1:16 AM Numan Siddique wrote:
> >
> > On Fri, Sep 3, 2021 at 3:28 PM Frode Nordahl
> > wrote:
> > >
> > > When OVN is linked with an appropriate plugging implementation,
> > > CMS can request OVN to plug individual lports into the local
> > > Open vSwitch instance.
> > >
> > > The port and instance record will be maintained during the lifetime
> > > of the lport and it will be removed on release of lport.
> > >
> > > Signed-off-by: Frode Nordahl
> >
> > Hi Frode,
> >
> > I've a few comments with the approach taken in this patch.
> > This patch calls the plug_port APIs from binding.c. This complicates
> > the already complicated binding.c code and I think plug_port() related stuff
> > can be handled separately. I don't see a need for binding.c to be aware of
> > plugging feature. For binding.c to claim a port, the ovs interface should
> > have external_ids:iface-id set to the port binding lport_name.
> >
> > Below is how I would see this can be done:
> >
> > 1. Add a new file called - controller/plug.c which will handle port
> > binding
> > changes - plug_handle_port_binding_changes (and possibly ovs
> > port/ovs interface changes).
> >
> > 2. The function plug_handle_port_binding_changes() will iterate through the
> > tracked port bindings and if the port binding has the required options
> > set
> > (i.e requested-chassis and plug-type) it will call plug_port APIs and
> > create
> > or delete OVS ports. This function can access the lbinding data
> > stored in the runtime data.
> >
> > 3. For recompute scenarios, there can be a function - plug_run() which
> > will
> > iterate through all the port bindings and create/delete ovs ports.
> >
> > 4. When the OVS ports are created / deleted in (2), in the next run,
> > the binding module
> > will claim or release the port binding. binding.c module
> > wouldn't need to care
> > if the port binding / ovs port is created by the plug module or
> > by some other
> > mechanism.
> >
> > 5. The functions plug_handle_port_binding_changes() can be either called by
> > runtime_data_sb_port_binding_handler() (i.e runtime engine node)
> > or another engine node for plug handling can be created which will
> > handle
> > port binding changes (and possibly ovs port/interface changes).
> > Similarly for full recompute, either runtime_data_run() can call
> > plug_run()
> > or a new engine run function can call it. Having a separate engine
> > node
> > seems better but then it needs to have runtime data as input
> > to access the lbinding information.
> >
> > 6. If you think plug.c should handle ovs port/interface changes, then you
> > can add handlers for it too.
> >
> >
> > What do you think ? Would this proposal work ? Let me know if
> > something is not clear
> > and I can try to explain better.
>
> Numan, thank you so much for the review and for providing such a
> detailed and complete counter proposal, this is most appreciated.
>
> I agree with you completely and have started working on such an approach.
Great. Thanks.
>
> This does mean I will most likely miss the 21.09 release with this
> series, which is unfortunate for me, but that's ok. Better to get it
> into a great shape for the next one than taking risks or cutting
> corners for this one.
If the patches look good before the official release, then I've no objection
to backporting to the newly created branch.
Thanks
Numan
>
> Cheers!
>
> --
> Frode Nordahl
>
> > Thanks
> > Numan
> >
> > > ---
> > > controller/binding.c| 247 ++--
> > > tests/ovn-controller.at | 31 +
> > > tests/ovn-macros.at | 2 +-
> > > 3 files changed, 272 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/controller/binding.c b/controller/binding.c
> > > index 938e1d81d..ae67ee3fc 100644
> > > --- a/controller/binding.c
> > > +++ b/controller/binding.c
> > > @@ -35,7 +35,9 @@
> > > #include "local_data.h"
> > > #include "lport.h"
> > > #include "ovn-controller.h"
> > > +#include "ovsport.h"
> > > #include "patch.h"
> > > +#include "plug.h"
> > >
> > > VLOG_DEFINE_THIS_MODULE(binding);
> > >
> > > @@ -45,6 +47,8 @@ VLOG_DEFINE_THIS_MODULE(binding);
> > > */
> > > #define OVN_INSTALLED_EXT_ID "ovn-installed"
> > >
> > > +#define OVN_PLUGGED_EXT_ID "ovn-plugged"
> > > +
> > > #define OVN_QOS_TYPE "linux-htb"
> > >
> > > struct qos_queue {
> > > @@ -71,10 +75,13 @@ binding_register_ovs_idl(struct ovsdb_idl *ovs_idl)
> > >
> > > ovsdb_idl_add_table(ovs_idl, _table_interface);
> > > ovsdb_idl_track_add_column(ovs_idl, _interface_col_name);
> > > +ovsdb_idl_track_add_column(ovs_idl, _interface_col_type);
> > > ovsdb_idl_track_add_column(ovs_idl,
> > > _interface_col_external_ids);
> > > ovsdb_idl_track_add_column(ovs_idl, _interface_col_bfd);
> > >
Re: [ovs-dev] [PATCH ovn v4 8/9] binding: Consider plugging of ports on CMS request.
On Fri, Sep 17, 2021 at 1:16 AM Numan Siddique wrote:
>
> On Fri, Sep 3, 2021 at 3:28 PM Frode Nordahl
> wrote:
> >
> > When OVN is linked with an appropriate plugging implementation,
> > CMS can request OVN to plug individual lports into the local
> > Open vSwitch instance.
> >
> > The port and instance record will be maintained during the lifetime
> > of the lport and it will be removed on release of lport.
> >
> > Signed-off-by: Frode Nordahl
>
> Hi Frode,
>
> I've a few comments with the approach taken in this patch.
> This patch calls the plug_port APIs from binding.c. This complicates
> the already complicated binding.c code and I think plug_port() related stuff
> can be handled separately. I don't see a need for binding.c to be aware of
> plugging feature. For binding.c to claim a port, the ovs interface should
> have external_ids:iface-id set to the port binding lport_name.
>
> Below is how I would see this can be done:
>
> 1. Add a new file called - controller/plug.c which will handle port binding
> changes - plug_handle_port_binding_changes (and possibly ovs
> port/ovs interface changes).
>
> 2. The function plug_handle_port_binding_changes() will iterate through the
> tracked port bindings and if the port binding has the required options
> set
> (i.e requested-chassis and plug-type) it will call plug_port APIs and
> create
> or delete OVS ports. This function can access the lbinding data
> stored in the runtime data.
>
> 3. For recompute scenarios, there can be a function - plug_run() which will
> iterate through all the port bindings and create/delete ovs ports.
>
> 4. When the OVS ports are created / deleted in (2), in the next run,
> the binding module
> will claim or release the port binding. binding.c module
> wouldn't need to care
> if the port binding / ovs port is created by the plug module or
> by some other
> mechanism.
>
> 5. The functions plug_handle_port_binding_changes() can be either called by
> runtime_data_sb_port_binding_handler() (i.e runtime engine node)
> or another engine node for plug handling can be created which will handle
> port binding changes (and possibly ovs port/interface changes).
> Similarly for full recompute, either runtime_data_run() can call
> plug_run()
> or a new engine run function can call it. Having a separate engine node
> seems better but then it needs to have runtime data as input
> to access the lbinding information.
>
> 6. If you think plug.c should handle ovs port/interface changes, then you
> can add handlers for it too.
>
>
> What do you think ? Would this proposal work ? Let me know if
> something is not clear
> and I can try to explain better.
Numan, thank you so much for the review and for providing such a
detailed and complete counter proposal, this is most appreciated.
I agree with you completely and have started working on such an approach.
This does mean I will most likely miss the 21.09 release with this
series, which is unfortunate for me, but that's ok. Better to get it
into a great shape for the next one than taking risks or cutting
corners for this one.
Cheers!
--
Frode Nordahl
> Thanks
> Numan
>
> > ---
> > controller/binding.c| 247 ++--
> > tests/ovn-controller.at | 31 +
> > tests/ovn-macros.at | 2 +-
> > 3 files changed, 272 insertions(+), 8 deletions(-)
> >
> > diff --git a/controller/binding.c b/controller/binding.c
> > index 938e1d81d..ae67ee3fc 100644
> > --- a/controller/binding.c
> > +++ b/controller/binding.c
> > @@ -35,7 +35,9 @@
> > #include "local_data.h"
> > #include "lport.h"
> > #include "ovn-controller.h"
> > +#include "ovsport.h"
> > #include "patch.h"
> > +#include "plug.h"
> >
> > VLOG_DEFINE_THIS_MODULE(binding);
> >
> > @@ -45,6 +47,8 @@ VLOG_DEFINE_THIS_MODULE(binding);
> > */
> > #define OVN_INSTALLED_EXT_ID "ovn-installed"
> >
> > +#define OVN_PLUGGED_EXT_ID "ovn-plugged"
> > +
> > #define OVN_QOS_TYPE "linux-htb"
> >
> > struct qos_queue {
> > @@ -71,10 +75,13 @@ binding_register_ovs_idl(struct ovsdb_idl *ovs_idl)
> >
> > ovsdb_idl_add_table(ovs_idl, _table_interface);
> > ovsdb_idl_track_add_column(ovs_idl, _interface_col_name);
> > +ovsdb_idl_track_add_column(ovs_idl, _interface_col_type);
> > ovsdb_idl_track_add_column(ovs_idl,
> > _interface_col_external_ids);
> > ovsdb_idl_track_add_column(ovs_idl, _interface_col_bfd);
> > ovsdb_idl_track_add_column(ovs_idl, _interface_col_bfd_status);
> > ovsdb_idl_track_add_column(ovs_idl, _interface_col_status);
> > +ovsdb_idl_track_add_column(ovs_idl, _interface_col_options);
> > +ovsdb_idl_track_add_column(ovs_idl, _interface_col_mtu_request);
> >
> > ovsdb_idl_add_table(ovs_idl, _table_qos);
> > ovsdb_idl_add_column(ovs_idl, _qos_col_type);
> > @@ -1090,6 +1097,51 @@ release_binding_lport(const struct sbrec_chassis
> >
Re: [ovs-dev] [PATCH ovn v4 8/9] binding: Consider plugging of ports on CMS request.
On Fri, Sep 3, 2021 at 3:28 PM Frode Nordahl
wrote:
>
> When OVN is linked with an appropriate plugging implementation,
> CMS can request OVN to plug individual lports into the local
> Open vSwitch instance.
>
> The port and instance record will be maintained during the lifetime
> of the lport and it will be removed on release of lport.
>
> Signed-off-by: Frode Nordahl
Hi Frode,
I've a few comments with the approach taken in this patch.
This patch calls the plug_port APIs from binding.c. This complicates
the already complicated binding.c code and I think plug_port() related stuff
can be handled separately. I don't see a need for binding.c to be aware of
plugging feature. For binding.c to claim a port, the ovs interface should
have external_ids:iface-id set to the port binding lport_name.
Below is how I would see this can be done:
1. Add a new file called - controller/plug.c which will handle port binding
changes - plug_handle_port_binding_changes (and possibly ovs
port/ovs interface changes).
2. The function plug_handle_port_binding_changes() will iterate through the
tracked port bindings and if the port binding has the required options set
(i.e requested-chassis and plug-type) it will call plug_port APIs and create
or delete OVS ports. This function can access the lbinding data
stored in the runtime data.
3. For recompute scenarios, there can be a function - plug_run() which will
iterate through all the port bindings and create/delete ovs ports.
4. When the OVS ports are created / deleted in (2), in the next run,
the binding module
will claim or release the port binding. binding.c module
wouldn't need to care
if the port binding / ovs port is created by the plug module or
by some other
mechanism.
5. The functions plug_handle_port_binding_changes() can be either called by
runtime_data_sb_port_binding_handler() (i.e runtime engine node)
or another engine node for plug handling can be created which will handle
port binding changes (and possibly ovs port/interface changes).
Similarly for full recompute, either runtime_data_run() can call
plug_run()
or a new engine run function can call it. Having a separate engine node
seems better but then it needs to have runtime data as input
to access the lbinding information.
6. If you think plug.c should handle ovs port/interface changes, then you
can add handlers for it too.
What do you think ? Would this proposal work ? Let me know if
something is not clear
and I can try to explain better.
Thanks
Numan
> ---
> controller/binding.c| 247 ++--
> tests/ovn-controller.at | 31 +
> tests/ovn-macros.at | 2 +-
> 3 files changed, 272 insertions(+), 8 deletions(-)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 938e1d81d..ae67ee3fc 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -35,7 +35,9 @@
> #include "local_data.h"
> #include "lport.h"
> #include "ovn-controller.h"
> +#include "ovsport.h"
> #include "patch.h"
> +#include "plug.h"
>
> VLOG_DEFINE_THIS_MODULE(binding);
>
> @@ -45,6 +47,8 @@ VLOG_DEFINE_THIS_MODULE(binding);
> */
> #define OVN_INSTALLED_EXT_ID "ovn-installed"
>
> +#define OVN_PLUGGED_EXT_ID "ovn-plugged"
> +
> #define OVN_QOS_TYPE "linux-htb"
>
> struct qos_queue {
> @@ -71,10 +75,13 @@ binding_register_ovs_idl(struct ovsdb_idl *ovs_idl)
>
> ovsdb_idl_add_table(ovs_idl, _table_interface);
> ovsdb_idl_track_add_column(ovs_idl, _interface_col_name);
> +ovsdb_idl_track_add_column(ovs_idl, _interface_col_type);
> ovsdb_idl_track_add_column(ovs_idl, _interface_col_external_ids);
> ovsdb_idl_track_add_column(ovs_idl, _interface_col_bfd);
> ovsdb_idl_track_add_column(ovs_idl, _interface_col_bfd_status);
> ovsdb_idl_track_add_column(ovs_idl, _interface_col_status);
> +ovsdb_idl_track_add_column(ovs_idl, _interface_col_options);
> +ovsdb_idl_track_add_column(ovs_idl, _interface_col_mtu_request);
>
> ovsdb_idl_add_table(ovs_idl, _table_qos);
> ovsdb_idl_add_column(ovs_idl, _qos_col_type);
> @@ -1090,6 +1097,51 @@ release_binding_lport(const struct sbrec_chassis
> *chassis_rec,
> return true;
> }
>
> +static void
> +consider_unplug_lport(const struct sbrec_port_binding *pb,
> + struct binding_ctx_in *b_ctx_in,
> + struct local_binding *lbinding)
> +{
> +const char *plug_type = NULL;
> +if (lbinding && lbinding->iface) {
> +plug_type = smap_get(>iface->external_ids,
> + OVN_PLUGGED_EXT_ID);
> +}
> +
> +if (plug_type) {
> +const struct ovsrec_port *port = ovsport_lookup_by_interface(
> +b_ctx_in->ovsrec_port_by_interfaces,
> +(struct ovsrec_interface *) lbinding->iface);
> +if (port) {
> +const struct plug_class *plug;
> +if
[ovs-dev] [PATCH ovn v4 8/9] binding: Consider plugging of ports on CMS request.
When OVN is linked with an appropriate plugging implementation,
CMS can request OVN to plug individual lports into the local
Open vSwitch instance.
The port and instance record will be maintained during the lifetime
of the lport and it will be removed on release of lport.
Signed-off-by: Frode Nordahl
---
controller/binding.c| 247 ++--
tests/ovn-controller.at | 31 +
tests/ovn-macros.at | 2 +-
3 files changed, 272 insertions(+), 8 deletions(-)
diff --git a/controller/binding.c b/controller/binding.c
index 938e1d81d..ae67ee3fc 100644
--- a/controller/binding.c
+++ b/controller/binding.c
@@ -35,7 +35,9 @@
#include "local_data.h"
#include "lport.h"
#include "ovn-controller.h"
+#include "ovsport.h"
#include "patch.h"
+#include "plug.h"
VLOG_DEFINE_THIS_MODULE(binding);
@@ -45,6 +47,8 @@ VLOG_DEFINE_THIS_MODULE(binding);
*/
#define OVN_INSTALLED_EXT_ID "ovn-installed"
+#define OVN_PLUGGED_EXT_ID "ovn-plugged"
+
#define OVN_QOS_TYPE "linux-htb"
struct qos_queue {
@@ -71,10 +75,13 @@ binding_register_ovs_idl(struct ovsdb_idl *ovs_idl)
ovsdb_idl_add_table(ovs_idl, _table_interface);
ovsdb_idl_track_add_column(ovs_idl, _interface_col_name);
+ovsdb_idl_track_add_column(ovs_idl, _interface_col_type);
ovsdb_idl_track_add_column(ovs_idl, _interface_col_external_ids);
ovsdb_idl_track_add_column(ovs_idl, _interface_col_bfd);
ovsdb_idl_track_add_column(ovs_idl, _interface_col_bfd_status);
ovsdb_idl_track_add_column(ovs_idl, _interface_col_status);
+ovsdb_idl_track_add_column(ovs_idl, _interface_col_options);
+ovsdb_idl_track_add_column(ovs_idl, _interface_col_mtu_request);
ovsdb_idl_add_table(ovs_idl, _table_qos);
ovsdb_idl_add_column(ovs_idl, _qos_col_type);
@@ -1090,6 +1097,51 @@ release_binding_lport(const struct sbrec_chassis
*chassis_rec,
return true;
}
+static void
+consider_unplug_lport(const struct sbrec_port_binding *pb,
+ struct binding_ctx_in *b_ctx_in,
+ struct local_binding *lbinding)
+{
+const char *plug_type = NULL;
+if (lbinding && lbinding->iface) {
+plug_type = smap_get(>iface->external_ids,
+ OVN_PLUGGED_EXT_ID);
+}
+
+if (plug_type) {
+const struct ovsrec_port *port = ovsport_lookup_by_interface(
+b_ctx_in->ovsrec_port_by_interfaces,
+(struct ovsrec_interface *) lbinding->iface);
+if (port) {
+const struct plug_class *plug;
+if (!(plug = plug_get_provider(plug_type))) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(,
+ "Unable to open plug provider for "
+ "plug-type: '%s' lport %s",
+ plug_type, pb->logical_port);
+return;
+}
+const struct plug_port_ctx_in plug_ctx_in = {
+.op_type = PLUG_OP_REMOVE,
+.ovs_table = b_ctx_in->ovs_table,
+.br_int = b_ctx_in->br_int,
+.lport_name = (const char *)pb->logical_port,
+.lport_options = (const struct smap *)>options,
+.iface_name = lbinding->iface->name,
+.iface_type = lbinding->iface->type,
+.iface_options = >iface->options,
+};
+plug_port_prepare(plug, _ctx_in, NULL);
+VLOG_INFO("Unplugging port %s from %s for lport %s on this "
+ "chassis.",
+ port->name, b_ctx_in->br_int->name, pb->logical_port);
+ovsport_remove(b_ctx_in->br_int, port);
+plug_port_finish(plug, _ctx_in, NULL);
+}
+}
+}
+
static bool
consider_vif_lport_(const struct sbrec_port_binding *pb,
bool can_bind,
@@ -1141,15 +1193,184 @@ consider_vif_lport_(const struct sbrec_port_binding
*pb,
if (pb->chassis == b_ctx_in->chassis_rec) {
/* Release the lport if there is no lbinding. */
if (!lbinding_set || !can_bind) {
-return release_lport(pb, !b_ctx_in->ovnsb_idl_txn,
- b_ctx_out->tracked_dp_bindings,
- b_ctx_out->if_mgr);
+bool handled = release_lport(pb, !b_ctx_in->ovnsb_idl_txn,
+ b_ctx_out->tracked_dp_bindings,
+ b_ctx_out->if_mgr);
+if (handled && b_lport && b_lport->lbinding) {
+consider_unplug_lport(pb, b_ctx_in, b_lport->lbinding);
+}
+return handled;
}
}
return true;
}
+static int64_t
+get_plug_mtu_request(const struct smap *lport_options)
+{
+return smap_get_int(lport_options, "plug-mtu-request", 0);
+}
+
+static bool
