Sasha, On Tue, Dec 16, 2008 at 2:43 AM, Sasha Khapyorsky <[email protected]> wrote: > Hi again, Hal, > > On 11:03 Mon 15 Dec , Hal Rosenstock wrote: >> On Mon, Dec 15, 2008 at 10:38 AM, Sasha Khapyorsky <[email protected]> >> wrote: >> > On 09:29 Mon 15 Dec , Mike Heinz wrote: >> >> >> >> That's a good question - and I'm going to ask around and double check. >> >> My first reaction was that you have to specify how many paths you want >> >> from the query - but you're right, the spec doesn't say that. >> > >> > Yes, it looks like this (but I cannot understand "why" :( ). >> >> The spec says this (for GetTable) and Gets are requests for 1 path. >> The reason is to limit the amount of returned path records (and the >> field limits to 255 records in the response). > > Do you know what is a reason for this "127 records" limitation?
Once you get past the scalability discussion (including limiting it to SGID), is there a need for more than 127 ? I think that allowing more paths is more important with various other types of wildcarded PR queries that are "beyond the spec". -- Hal >> >But even more >> > strange (IMHO) limitation is mandatory SGID - actually it should make >> > illegal such GetTable queries as all-to-all, SLID-to-all, etc.. I >> > thought that it is permitted. >> >> It was decided to force SGID. Neither All to all nor SLID to all by >> itself are spec'd (you could could add SGID along with SLID to all >> though). Support for those is a proprietary OpenSM extension which is >> used for testing at least (and also by saquery command). > > Ok. Not a bad extension IMHO :) > > Sasha > _______________________________________________ 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
