[openib-general] gen2/rnic-pi differences

Fab Tillier ftillier at silverstorm.com
Fri Jul 1 09:37:56 PDT 2005


> From: Caitlin Bestler [mailto:caitlinb at siliquent.com]
> Sent: Friday, July 01, 2005 9:15 AM
> 
> RNIC-PI defined several verb layer features that if supported
> eliminate the need for a DTO_COOKIE. If the information can
> be integrated with existing verb layer structures it is a
> major improvement in efficiency, at worst case it merely
> requires the verb layer to implement the same workarounds
> that the Access Layer is already forced to use.
> 
> These features are:
> 	all verb layer objects have a consumer supplied
> 	identifier (os_data) that is used to identify that
> 	object back to the consumer in all completions and
> 	callbacks. So instead of getting the QPID you get
> 	the EP pointer (assuming that is what you supplied).

This should be really easy to implement for Mellanox HCAs - the mthca driver
already has to resolve the QP structure when processing completions, and getting
the user's QP context and including it in the work completion should be a
trivial addition (for someone familiar with the code base).

> 	Three flags are identified per work request that can
> 	be ignored, passed through or fully implemented. They
> 	are Local Solicited, Consumer0 and Consumer1. If 'Local
> 	Solicited' is defined it means that completion of the
> 	work request should be treated as though it were a
> 	solicited event (i.e., it qualifies for 'next solicited
> 	event' callback notification).

Would these flags be returned in the work completion?  I don't know if I quite
understand what you're requesting here.  Do Consumer0 and Consumer1 represent
bits in a flags field?

In the Mellanox HCA implementation, the 64-bit work request ID is stored by the
driver and recovered upon a completion.  Basically, the HCA driver maintains
DTO_COOKIE-like information for each work request already.  Due to this lookup
requirement, the information stored per work request could be arbitrarily large
if so desired.  I don't know if that holds true for the PathScale HCA hardware,
though - if it doesn't it would require an additional lookup in the HCA driver
to get back to this information, in effect pushing the DTO_COOKIE concept into
the HCA driver rather than leaving it in the consumer.

- Fab




More information about the general mailing list