On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) <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
