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