Re: [PATCH 0/2] Add support for enhanced atomic operations

[Vladimir Sokolovsky <vlad-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

Hal Rosenstock wrote:
> On Wed, Feb 3, 2010 at 3:01 AM, Vladimir Sokolovsky
> <vlad-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>> Sean Hefty wrote:
>>>> Will Mellanox be adding this option to the IB spec rather than keep it
>>>> as vendor proprietary ?
>>> Along with that question, what is the use case for this feature?  The only
>>> benefit mentioned was saving a few bytes of memory, at the cost of
>>> carrying
>>> extra network headers.  Atomics are only 64-bits to begin with...
>>>
>>
>> For some applications the memory savings are very significant. One
>> example is fine grain lock implementations for huge data sets. In other
>> cases, the benefit is the ability to update multiple fields with a
>> single io operation.
> 
> What happens when the other end doesn't support this feature (new
> opcodes) ? How can that be determined remotely ? Is some CM related
> change also needed ?
> 
> -- Hal
> 

In this case the responder (the other end) will return a NAK-Invalid Request
to the requester.
There is no need to extend the CM protocol. This can be done as part of
application negotiation. Atomic is an optional feature and the CM is not
involved in negotiation of this. Application to application should decide
if they want and they can use atomic. The same should be done for extended
atomics.

Regards,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html