> This caught my eye on Friday but it was Beer-thirty. ;-) > > I'm also not sure "protocol" is sufficient. There are many devices > which support multiple protocols: OmniPath == verbs _and_ PSM, RoCE > == sockets (TCP, UDP, HTTP, SSL?) _and_ roce, usNIC == Sockets and > libfabric... ? (what is the underlying "protocol" here? Does it > matter?) ???
Well, I consider verbs, psm, and sockets APIs, not protocols. How much beer did you ingest? :) I guess you could argue for psm as a protocol, and roce is as well. > I just end up asking myself "what is a protocol"? There are so many > definitions and depending on the level you are discussing it gets > pretty confusing. > > Should we have a list here? Or do you get multiple fid_attr for > each "protocol"? To be clear, the proposed attributes are associated with a specific struct fi_info, plus other substructures (domain_attr, ep_attr, etc.). The data is retrieved as part of calling fi_getinfo(), NOT some sort of get_device_info() call. > What about listing APIs supported? Verbs, Sockets, whatever GNI, > BlueGene, usNIC are? This is for libfabric, so I don't see a reason for it to tell the app that, hey, other APIs are supported. As soon as the device supports TCP, it technically supports nearly all other APIs. - Sean _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
