Hi Jon,
I don’t think the renumber scheme, as used by vhost and tap interfaces, is
foolproof and can cause problems if used extensively for vxlan. On creating an
interface with renumber, it does not check if the instance being requested is
already used by another device. On creating an interface without renumber, it
also does not check if the “natural instance’ may have already been used by
another device’s renumber. Thus, on instance collision, last interface will
take over the interface name and leave the previous interface not accessible
by the duplicated interface name.
I think we must check and reject instance misuse for this to be acceptable. I
doubt the renumber is really used much for vhost and tap interface (others
please correct me if not true). I see a “FIXME” warning in the existing vhost
renumber function:
static int
vhost_user_name_renumber (vnet_hw_interface_t * hi, u32 new_dev_instance)
{
// FIXME: check if the new dev instance is already used
vhost_user_main_t *vum = &vhost_user_main;
vec_validate_init_empty (vum->show_dev_instance_by_real_dev_instance,
hi->dev_instance, ~0);
In your previous patch set #1, the usage of a bitmap to track instance usage
seem a reasonable solution. It does imply we will never use “natural” instance
and would always use the instance allocated from the bitmap and stored in the
tunnel struct.
As for the API/CLI, I though another parameter “instance” would suffice as ~0
can be used to state “not specified” rather than having an additional parameter
“renumber”, although I can accept either way.
Regards,
John
From: Jon Loeliger [mailto:[email protected]]
Sent: Sunday, February 04, 2018 3:38 PM
To: John Lo (loj) <[email protected]>; Dave Barach (dbarach) <[email protected]>
Cc: vpp-dev <[email protected]>
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names
On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj)
<[email protected]<mailto:[email protected]>> wrote:
Hi Jon,
All VPP tunnel creation uses the mechanism of returning a sw_if_index of the
created tunnel. The name of the tunnel is then followed by a number being the
instance or index to the tunnel struct vector. Thus, the first VXLAN tunnel
created is called vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is
incrementing unless tunnels are deleted and created again where a newly created
tunnel will reuse the last deleted tunnel, hence its name. If all previously
deleted tunnels are used up, then the tunnel name number will start
incrementing again. I am not sure if it is feasible to follow this behavior to
“predict” tunnel name.
John and Dave,
I have uploaded a new patch set. It is being verified at the time of this
writing.
This patch has a different implementation than the previous version.
The API changes, including VAT-n-friends, have been updated a bit,
but the basic mechanism of obtaining predictable SW IF names is
different from my original patch.
In the current form, I followed an existing "custom device instance" pattern
that was already present on several other objects already. Much simpler,
and I expect it to verify now. :-)
So, I guess I realize my mistake in my previous discussions of this general
problem
I apparently wasn't using the right words. I was saying something like "The
User
needs to be able to know or predict the SW IF name." The phrase that seems to
be used specifically for this purpose in many other places is "Let the user
assign
a custom device instance id." And that is achieved via the use of the so-called
*_name_renumber() class function.
So my earlier plea for a "can we somehow solve this at a higher level" might
be more properly stated as: Where objects are created as a side-effect of
some other creation request, a "renumber flag and custom device instance"
would be really nice on the Create API call.
HTH,
jdl
_______________________________________________
vpp-dev mailing list
[email protected]
https://lists.fd.io/mailman/listinfo/vpp-dev
