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:j...@netgate.com] Sent: Sunday, February 04, 2018 3:38 PM To: John Lo (loj) <l...@cisco.com>; Dave Barach (dbarach) <dbar...@cisco.com> Cc: vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] VXLAN Tunnel IF Names On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 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 vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev