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.



_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to