>One could ask the IBTA for this if it is the right thing to do. Checking with the IBTA makes sense. Longer term, adding a distributed SA application class, or expanding the existing SA class may be useful, if the IBTA wants to define SA implementation at this level of detail. However, I was trying to focus on what could be done now. If the IBTA would like to standardize the communication, that'd be great.
One issue that isn't clear to me is what exactly is meant by the statement: "Vendor-specific classes will never be used to define management operations that are encompassed by the Infiniband Architecture." For example, suppose that there were a small number of SA caches available in the subnet. Is it compliant for a node to issue a PR query to one of the caches using a vendor-defined PR query? Or must this be done using an SA PR query with possible redirection? >Are you saying to make the RMPP header as the first part of Data ? Yes. >Vendor class 1 are not RMPP MADs so I think this is nonconformant. I didn't see any restriction on the vendor class 1 data - at least in section 16.5. If I'm mistaken on this, then I agree that vendor class 2 seems to be our only current option. >That's one reason vendor class 2 was added. In addition, there is no way >to detect one "vendor" from another "vendor" (which is why OUI was >added) if the same class is used so these need to be unique across all >vendors. Yes - all vendor class 1 MADs suffer from this issue. In practice, it seems that there can only be a single vendor for a given class on a subnet. >The only choice seems to me to be reformatting using vendor class 2 and >dealing with the data copying. >From an implementation viewpoint, this just seems less desirable. Adding the offset means that single-segment SA MAD may become our multi-segment vendor MAD, and dealing with two MAD formats will be troublesome. If we're only caching PRs, this may not be a big deal, but if we ever want to create a truly distributed SA, I think it will be. - Sean _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
