[openib-general] Re: [RFC][PATCH] OpenIB uDAPL extension proposal - sample immed data and atomic api's

[Arlin Davis]

James Lentini wrote:

>On Fri, 23 Dec 2005, Arlin Davis wrote:
>
>arlin>
>arlin> A single entry point is still there with this patch, I just 
>arlin> defined it a little different with a function definition for 
>arlin> better DAT API mappings. The idea was to replace the existing 
>arlin> pvoid extension definition with this new one. Can you give me 
>arlin> an idea of how you would map these extended DAT calls to this 
>arlin> pvoid function definition?
>
>For uDAPL, the DAT_PROVIDER structure is defined as follows:
>
>struct dat_provider
>{
>    const char *                        device_name;
>    DAT_PVOID                           extension;
>    ...
>
>You could create a well known extensions API by defining a structure 
>with several function pointers
>
>struct dat_atomic_extensions
>{
>    DAT_RETURN (*cmp_and_swap_func)(IN DAT_EP_HANDLE ep_handle,
>                                    IN DAT_UINT64 cmp_value,
>                                    IN DAT_UINT64 swap_value, 
>                                    IN DAT_LMR_TRIPLE *local_iov, 
>                                    IN DAT_DTO_COOKIE user_cookie, 
>                                    IN DAT_RMR_TRIPLE *remote_iov, 
>                                    IN DAT_COMPLETION_FLAGS completion_flags);
>    ...
>}
>
>and require the dat_provider's extensions member to point to your new 
>extension struct.
>
>To make the API easier to use, you could also create macros, similar 
>to the standard DAT macros, to reach inside an objects provider 
>structure and call the correct extension function.
>
>#define dat_ep_post_cmp_and_swap(ep, cmp, swap, local_iov, cookie, 
>remote_iov, flags) \
>        (*DAT_HANDLE_TO_EXTENSION (ep)->cmp_and_swap_func) (\
>                (ep),               \
>                (cmp),              \
>                (swap),             \
>                (local_iov),        \
>                (cookie),           \
>                (remote_iov),       \
>                (flags))
>
>A drawback to this approach is that adding new extensions requires 
>synchronizing with the original extension specification document. To 
>eliminate that issue, you could require that the dat_provider's 
>extension member point to a typed list of these sorts of extension 
>structures.
>  
>
The other drawback is that the consumer calls directly into a table with 
no validation of provider extensions nor handles. The method I am 
proposing uses the existing dat_api layer for handle validation, a 
provider extension validation during the open, and provider extension 
operation validation with the extension operation parameter in the new 
DAT_EXTENSION_FUNC typedef.