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
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
I apparently wasn't using the right words. I was saying something like
needs to be able to know or predict the SW IF name." The phrase that seems
be used specifically for this purpose in many other places is "Let the user
a custom device instance id." And that is achieved via the use of the
*_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.
vpp-dev mailing list