> On 12 Oct 2018, at 17:53, Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Thu, Oct 11, 2018 at 02:44:03PM -0400, Hal Rosenstock wrote: >> On 10/11/2018 10:00 AM, Jason Gunthorpe wrote: >>> On Wed, Oct 10, 2018 at 05:16:28PM -0400, Hal Rosenstock wrote: >>>> On 10/10/2018 3:53 PM, Hefty, Sean wrote: >>>>>> Thanks Sean. Should I then the remove the port number from the triple, >>>>>> or keep it for legacy reasons? >>>>>> >>>>>> Hal's concern about backward compatibility vs. the address file, does >>>>>> that need to be addresses in your opinion? >>>>> >>>>> I would maintain compatibility, maybe you can use the number of inputs to decide between port versus node guid. >>>> >>>> Yes, that's what I was thinking in terms of backward compatibility. >>> >>> Why not increase or remove the internal limit instead of making any >>> user visible change? >> >> I think there were 2 issues: >> 1. number of endpoints supported was limited to 4 >> 2. using port guid rather than/in addition to node guid and port number >> in acm address config file > > I had understood that #1 was a side effect of #2 and using the port > guid somehow avoided the limit? Yes, sort of. If Port GUID is used to associate an endpoint, the demand for endpoint addresses will diminish. One could increase the limit, but to what? PCIe's SR-IOV Extended Capability TotalVFs ate 16 bits, so worst case is not practical. Better to allocate dynamically. >> I can see how #1 can be changed without user visible change but not sure >> if/what you had in mind for #2. > > I was thinking if we fix #1 we don't even need to care about #2? For my case, yes. > For the most part this is all internal and automatic, right? But enlighten me about the user visible change if Port GUID is implemented. The GUIDs are not listed in the address file to my knowledge. Thxs, Håkon
