[ofiwg] lifabric provider extensions

Cheng, Wendy wendy.cheng at intel.com
Fri Oct 31 10:19:53 PDT 2014

This is good and helpful .. Hopefully it'll keep core SFI functions small and concise.

n  Wendy

From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-bounces at lists.openfabrics.org] On Behalf Of Reese Faucette (rfaucett)
Sent: Friday, October 31, 2014 10:08 AM
To: ofiwg at lists.openfabrics.org
Subject: [ofiwg] lifabric provider extensions

I have this idea of how providers might add calls in the rare event its needed, but would like to run it by the list for comments.
Let's say provider xyzzy supportsa new call AV-related call, "fi_av_xyzzy_add_flux()".  The would be a new header "fi_xyzzy.h" and "xyzzy_av.c" as shown below.

Does this seem sane?  I think the "version" passed to fi_getinfo can be used to deal with fi_ops_av growing wrt. Backwards compatability.


======= fi_xyzzy.h ========

struct fi_ops_av_xyzzy {
       struct fi_ops_av base_ops;
       int (*add_flux)(struct fid_av *av, ssize_t flux_value);

static inline int
fi_av_xyzzy_add_flux(struct fid_av *av, ssize_t flux_value)
       return ((struct fi_ops_av_xyzzy *)av->ops)->
              add_flux(av, value);

====== xyzzy_av.c ==========

struct fi_ops_av_xyzzy xyzzy_av_ops = {
       .base_ops = {
              .size = sizeof(struct fi_ops_av_xyzzy),
              .insert = xyzzy_av_insert,
       .add_flux = xyzzy_av_add_flux;

int xyzzy_av_open(...)
       av->ops = (struct fi_ops_av *)&xyzzy_av_ops;
       return 0;

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20141031/4872b67b/attachment.html>

More information about the ofiwg mailing list