Cathy, team, In scoping out what would be necessary to implement an automatic link naming scheme for tunnels (assuming that Darren and David's feedback would lead us in that direction), I've run into a roadblock.
The order of operations today for tunnel creation in clearview_iptun (with a required linkname) is as follows: 1. libiptun:iptun_create() allocates a linkid by calling dladm_create_linkid(<tunnelname>, ...). This allocates a linkid and associates it with <tunnelname> in linkmgmtd. 2. libiptun:iptun_create() sends down an IPTUN_CREATE ioctl which contains the linkid that was allocated in step 1. 3. IPTUN_CREATE calls mac_register() for the new tunnel, which requires a pre-allocated linkid. Conveniently, we have the linkid since it was passed down as part of the ioctl data. 4. mac_register() results in an upcall to linkmgmtd to find the link name associated with the linkid, and the proper link is magically created with the correct name. The problem here is that if we don't have the tunnel name in step 1 (as would be the case if the tunnel name is not required input for tunnel creation), we cannot allocate a linkid, and we can therefore not call mac_register() in step 3. We cannot generate the link name prior to step 1 because the kernel is the only place where we can atomically find the best available tunnel name. Tunnel name generation is best done as part of the IPTUN_CREATE ioctl processing. Therefore, we need a function to allocate a linkid from the kernel, and I don't believe the UV gate has such a function. That way, the IPTUN_CREATE ioctl can generate a link name, call the linkid allocation function (which would presumably result in a door upcall to linkmgmtd), then call mac_register() with the resulting linkid. Thoughts? -Seb
