[openib-general] [RFC] [PATCH] SRQ API

Caitlin Bestler caitlin.bestler at gmail.com
Wed Jun 15 14:49:08 PDT 2005


On 6/15/05, Roland Dreier <roland at topspin.com> 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.



More information about the general mailing list