[EMAIL PROTECTED] wrote: > Roland Dreier wrote: >> This reminds me of something I've been meaning to ask: what is the >> attr_mask of the query QP function used for? The verbs definition in >> the IB spec does not include an attribute mask. Obviously we don't >> have to follow the spec precisely but I'm wondering what the >> advantage is in having an attribute mask for query QP. None of the >> other query methods (including query SRQ) have an attribute mask. > > My understanding of the original code that this came from is > that it permitted querying attributes that may be stored in > memory, rather than requiring reading the card. E.g. if all > you needed was the QPN, then you could obtain only that > information. Given that things like the QPN, QP type, etc. > are already available through the API, I'm not sure that the mask is > needed. >
Anticipating what queries are expensive (require a round-trip to the card) is inherently model dependent. Having an attribute mask allows the consumer to state *exactly* what informatino is required, and allowing each driver to decide whether a round-trip to the card is needed for *this* set of information. It should be clear that the provider MAY supply answers that were not requested but SHOULD NOT take extra steps to obtain that information. That is, a provider could first copy all the data in had on-host, and then check a flag to see if a round-trip to the device was required. If so it might just copy everything from the device. This style was selected in both DAT and IT-API because it simpler to use this type of attribute uniformly rather than expecting the consumer to remember which queries might be issues on *some* devices. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general