[openib-general] RE: [RFC] DAT 2.0 immediate data proposal

[Arlin Davis]

Kanevsky, Arkady wrote:

>Arlin,
>I am not convinced we need a new recv for immediate data.
>But what is needed is change in normative text in many places.
>Recv, RDMA Write, DTO completion events, error behavior.
>Sure you can define immed data in extension but it still effects
>behavior of the normative part of the spec.
>  
>
How does it effect the normative part of the spec outside of the DTO 
event extension?
The post_recv behaves exactly the same.

>This is why my preference is to put it into the main spec.
>  
>
ok, with no new recv_immed call we do get a little closer.

>The xfer_size is minor thing. We just need to define it meaning
>with respect to immed_data. Defining it either way is fine.
>
>Handling extra space on CQ can be handled by Provider.
>We can add a new EVD attribute for the use for handling RDMA_write with
>immed
>data and Provider can automatically add extra space on CQ.
>Provider is already responsible to handing user a single completion.
>SO it will only be used for error handling.
>  
>
sounds good.

>Error handling takes maost of the new write up anyhow.
>Regardless where it is done in the spec or in extension.
>
>Question on do we want to support Send with immed_data have to be
>decided.
>Ditto remote RMR invalidation with new post(s) for immed_data.
>Just because IB supports all possible correlation under one Send post
>does not mean that uDAPL should follow that too.
>  
>
I would agree, strike them all except rdma_write_immed.

Can you give some idea how you would write up the normative text for the 
transport independent receive that would accept immediate data?

thanks,

-arlin