[ofiwg] getting hardware details from libfabric

Brice Goglin Brice.Goglin at inria.fr
Tue May 29 12:02:56 PDT 2018


Le 29/05/2018 à 15:05, Jeff Squyres (jsquyres) a écrit :
>
>> On May 24, 2018, at 8:49 PM, Hefty, Sean <sean.hefty at intel.com> wrote:
>>
>> This is an initial proposal:
>>
>> 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.
>>
>>
>> // 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;
>> 	};
> It would probably good to have some guidance for what to put in these fields.  Nothing too restrictive, but something to help vendors/provider authors have some semblance of commonality between these fields (I speak as a vendor who got burned on this exact issue before ;-) ).
>
> Here's a first cut:
>
> Interface: OS device name (if this is a filename, it should be an absolute filename)
> Device ID: ...I'm not clear on how this is different than vendor ID?
> Device version: Vendor hardware version
> Vendor ID: Vendor hardware part ID
> Firmware: Vendor firmware version

Device and vendor IDs are different: in PCI, you have things like
1137:0043 for Cisco usNIC devices. 1137 is the vendor ID (string "Cisco
Systems Inc") while 0043 is the device ID ("VIC Ethernet NIC") within
Cisco's list of hardware.

In PCI, there's also an optional submodel and subdevice IDs (can be used
when a vendor ships another vendor's hardware).

Otherwise, it looks good.


> Should we add a driver name field?
>

I think so.

Brice



More information about the ofiwg mailing list