We use an atomic counter to create unique names for OPTE ports, done here. It's possible that this name conflicts with an existing data link, but that the link does not show up in dladm output (which we use to clean up any old links when the sled-agent starts). In that case, we will get an EEXIST from the call to create_xde.
There are a few options. We can just skip the name as long as we get EEXIST, or we can update the xde driver to forcibly remove or overwrite that existing name. The latter is based on the assumption that if we get a link that we cannot see with dladm, it's by definition a leaked resource that can and should be clobbered. It's not yet clear who should do the clobbering (xde or sled-agent), or how they'd do that. One reason to take option one (skipping the name) is that this would preserve the system state for debugging and forensics.
We use an atomic counter to create unique names for OPTE ports, done here. It's possible that this name conflicts with an existing data link, but that the link does not show up in
dladmoutput (which we use to clean up any old links when the sled-agent starts). In that case, we will get anEEXISTfrom the call tocreate_xde.There are a few options. We can just skip the name as long as we get
EEXIST, or we can update thexdedriver to forcibly remove or overwrite that existing name. The latter is based on the assumption that if we get a link that we cannot see withdladm, it's by definition a leaked resource that can and should be clobbered. It's not yet clear who should do the clobbering (xdeor sled-agent), or how they'd do that. One reason to take option one (skipping the name) is that this would preserve the system state for debugging and forensics.