Re: About a shortcoming of the verbs API

Bart Van Assche
2010-07-26T17:59:44Z

On Mon, Jul 26, 2010 at 4:21 PM, Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote:
> On 07/25/2010 01:54 PM, Bart Van Assche wrote:
>>
>> [ ... ]
>>
>> The only way I know of to prevent out-of-order completion processing
>> with the current OFED verbs API is to protect the whole completion
>> processing loop against concurrent execution with a spinlock. Maybe it
>> should be considered to extend the verbs API such that it is possible
>> to process completions in order without additional locking. Apparently
>> API functions that allow this in a similar context have already been
>> invented in the past -- see e.g. VipCQNotify() in the Virtual
>> Interface Architecture Specification.
>
> Is this the API to which you refer?
>
> http://docsrv.sco.com/cgi-bin/man/man?VipCQNotify+3VI
>
> I don't see how it provides the semantics you desire?

The web page you refer to is owned by a company that is controversial
in the Linux world. A more neutral source is the book "The Virtual
Interface Architecture" (Intel Press, 2002) or the document "Virtual
Interface Architecture Specification" (1997, available online at
http://pllab.cs.nthu.edu.tw/cs5403/Readings/EJB/san_10.pdf). In both
documents it is described that VipCQNotify atomically either dequeues
a work completion or enables notifications. As far as I know none of
the verb extensions defined by the IBTA allows to perform both
operations in an atomic way.

Bart.