Hi all, Sorry for late reply as I was not in the office.
Please anybody just tell me about the idea of _distributed SA_ in short. Is it a pre-planed activity which is yet to be implemented with the OFED? or its just an extension of the sa cache pre-loading discussion? And again distributed SA is going to solve what purpose? On 06 Jun 2007 05:45:12 -0400, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
On Wed, 2007-06-06 at 00:06, Sean Hefty wrote: > >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." I'm not sure pf the intent of this but that is informative rather than normative (compliance) text. > 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? I think this example falls would fall "on the line" and seems somewhat debatable as to whether there is a management operation for this or not. It does go back to the intent of the original statement you cited. > >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. True but I'm not sure that was the intent which again was why vendor class 2 was created. Also, there is the problem of knowing that this vendor class 1 is using RMPP. That sounds proprietary to me (and affects the kernel in the OpenIB implementation). > 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. That's one way of putting it but limits the use; in fact, if this were done, all subnets would use at least two different vendors. Another way is that all vendors who want to use this class range need to coordinate such use (e.g. class allocation). > >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. Are you referring to the performance hit ? -- Hal > - 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
