Everyone in the US is starting their 3-day week-end early, which makes this the
perfect time to have a conversation with myself.
> The device attributes are per fi_info structure (which includes the
> network address, domain, and ep attributes). The app does not need
> to open any resources to obtain the data.
>
>
> When fi_getinfo() is called with FI_DEVICE_ATTR flag set, each
> fi_info::handle will reference a struct fid_attr, if valid.
We can drop the FI_DEVICE_ATTR flag and make this the default. This requires
that fi_freeinfo() free the handle.
> // Definition of struct fid_attr. Field types could change.
> struct fid_attr {
> struct fid; /* fclass = FI_TYPE_DEVICE_ATTR */
> struct dev_attr {
> char *interface;
> char *device_id;
> char *device_version;
> char *vendor_id;
> char *firmware;
> };
> struct bus_attr {
> char *domain_id;
> char *bus_id;
> char *device_id;
> char *function_id;
> };
I have no idea how to obtain this data outside of Linux, or if it is generic
enough to handle anything but PCI.
> struct link_attr {
> char *address;
> size_t mtu;
> enum fi_link_state state; /* up, down, unknown */
> char *protocol;
> size_t speed; /* bits per second */
> };
> struct prov_attr {
> size_t size;
> char data[];
> };
> };
>
>
> The prov_attr structure can be cast to a provider specific structure
> (e.g. usnic_devinfo) if the app knows the structure format. I would
> add a new public header for all definitions. Additionally,
> fi_tostr() can be used to display the attributes. fid_attr allows
> fi_tostr() to route the call to the provider to handle the prov_attr
> portion (done using new fi_control FI_TOSTR option).
The additional attributes would be reported by the fi_info utility
automatically - no code changes needed.
- Sean
_______________________________________________
ofiwg mailing list
[email protected]
http://lists.openfabrics.org/mailman/listinfo/ofiwg
