On 6/15/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > Here's a first stab at the changes to the API in <ib_verbs.h> required > to support shared receive queues (SRQs). SRQs are described in > version 1.2 of the IBA spec; specifically, sections 10.2.9 and 11.2.3 > describe the semantics and verbs interface. > > I did diverge from the spec in that instead of a single "Post Receive > Request" verb, there are separate ib_post_recv() and > ib_post_srq_recv() functions. This avoids complications from having a > polymorphic function that takes either a QP or an SRQ, and matches the > interface Mellanox used in VAPI. > > Any comments?
I definitely agree on having two methods. If you want one method then it should accept the QP pointer all the time and merely redirect to the SRQ. Two totally distinct methods with signatures calling for the specific handle type allows the code to get right to work, not act as a sub-dispatcher. Polymorphism at run-time should only apply when the same actions are taken no matter what the type is. I would recommend defining warning events associated with SRQ usage. Omitting them creates glaring security vulnerabilities. DAT/IT-API define an SRQ low-watermark (event when number of buffers in SRQ falls below set level), per RQ soft high-watermark (event when one QP allocates more than N uncompleted buffers) and a per RQ hard high-watermark (connection terminated when more than N buffers required for one QP). The first two are defined for iWARP/RDMAC, the third is optional under RNIC-PI. Without such events a server attempting to use an SRQ to support multiple client will be subject to a Denial of Service attack from one client that threatens to kill or stall other connections. But servers supporting multiple clients are *exactly* the type of application that would benefit the most from SRQs. Of course you can't force any hardware that doesn't generate those warnings to do so, but if the API doesn't have the concept then you can *never* get those warnings. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
