Hal Rosenstock wrote:
On Wed, Feb 3, 2010 at 3:01 AM, Vladimir Sokolovsky
<[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
