John, On Mon, Feb 5, 2018 at 2:14 PM, John Lo (loj) <l...@cisco.com> wrote:
> Thanks Jon. Seems we have an agreed upon an approach now. Just to be > sure, let me list the specifics: > > > > 1. We will get rid of custom_instance_by_real_instance vector in > vxlan_main_t > See #3 below. > 2. We will add something like user_instance_by_real_instance hash in > vxlan_main_t to track instance usage. > Yes. > 3. We will add u32 instance in vxlan_tunnel_t to keep user specified > instance, which will be the same as real instance or index of vxlan tunnel > in the tunnels vector in vxlan_main. > > I am happy to do this, yes. However, there is some reason that this number can not be used directly within the format() of the vxlan_tunnel%d name. At the time that the reuse of the HW IF happens, the necessary name_renumber() call fails to get the right instance number as the hw_if_index isn't set in the hi struct properly yet. This is why the custom_instance_by_real_instance mechanism works: it is always available. I will endeavor to use just the hash and the instance on the tunnel struct. I will attempt to resolve the issue described in the previous paragraph in more detail. I know that was a bit vague, so I'll attempt to nail-down the real issue I was seeing. 4. We will replace the 64 byte if_name in the vxlan_tunnel_details API > with u32 instance. > Yes. > 5. We will generate instance-in-use API error if vxlan tunnel > creation cannot use the desired instance, either natural or specified. > Yes. We also have to guarantee that: in the case of default allocation (ie, not specified by the user/API), that there still always a successful allocation. (Ie, a bit of searching for a valid instance might take place.) I don't think this will be a problem in general. it will likely only be noticed when both default and specified allocations are intermixed. > Will review your new patch set when it shows up. Once you patch is > merged, I will copy the same mechanism into the GRE tunnel update I am > currently working. I will submit my GRE patch for review sometime later and > add you as one of the reviewers. > Awesome! Sounds great! > Thanks, > > John > Thanks, jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
