Hi Jon, I think a good approach would be to store the insurance number in the tunnel struct and use a hash table to track instance number usage. This is a more effective way to not waste memory even for user who like to use big numbers for instance while not using that many tunnels. The instance number in the tunnel struct would be the natural one if not specified by user. We will need an “instance number in-use” API error. For users who always use default or always specify instance number, there should not be any problem and the current default instance behavior is preserved. For users that use mixed mode to create tunnels, if a natural one is not available, the API error will force the user to specify a usable instance number. What do you think?
About the renumber param in API, I suppose it is better in the sense that Python binding always default non-specified parameters to 0 and thus more user friendly. An alternative would be to use instance 0 as “not specified” so any user specified instance number must be > 0. As for GRE tunnel, I am in the process of making a major change to it to support ERSPAN encap that is built on top of TEB support. There were two interface names used, greN or teb-greN, depending on payload type (and also tunnel interface type) while sharing the same instance space for N. This is kind of awkward to me and I have changed this to use greN interface name only. I removed the interface reuse logic on tunnel creation to prevent the problem caused by having to reuse the right interface type. Thus tunnel create/delete always create and delete associated interfaces. Once we agreed on instance mechanism for VXLAN, I will also include it in my change to GRE since I am changing the API anyway. Regards, John From: Jon Loeliger [mailto:j...@netgate.com] Sent: Monday, February 05, 2018 11:49 AM To: John Lo (loj) <l...@cisco.com> Cc: Dave Barach (dbarach) <dbar...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] VXLAN Tunnel IF Names On Mon, Feb 5, 2018 at 9:55 AM, Jon Loeliger <j...@netgate.com<mailto:j...@netgate.com>> wrote: 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). We do use them on every call we make to these functions. As well as on loopbacks. Knowing what object (by name) will b created is essential for us. 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. That said, we can combine the two approaches. That is, use the show_instance_by_real_instance vector for knowing what name to use, but also use a bitmap to record what was used and allocated. One question on the bitmap approach. It had a hard-coded upper limit of 16K bits in my previous patch. Are people OK with that? It is arbitrary, and could be larger. It simply depends on how much memory folks are willing to spend recording in-use bits. That or a search of the show_by_real vector. Or we could convert to a hash-map to check "in-use" status. Preference? John, Also as a point of information, I'd like to follow this approach for GRE as well as soon as we agree on an approach here! Thanks! jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
