> However, getting this wrong limits the future hardware we can support, > which is scary, and the branch option clearly doesn't have that > problem. > > So the performance win would have to be substantial, IMHO. I agree that we need to be careful about exposing implementation specific details through the API, but we're already partially down that path. I'm not sure about the best way to measure performance with any proposal. These are more thoughts than questions: If an app wants to support iWarp/RoCE/OPA, is it just going to have a branch around the calls anyway? What data is actually needed by the apps? Is there any relationship between the various calls? For example, if an app calls read_slid, is it more likely than not to also call read_pkey_index and read_dlid_path_bits, etc.? Is the app expected to retrieve addressing data piecemeal like this for every possible architecture? Are 5 function calls better than one call that fills out a structure, when all fields are needed? Basically, meaningful benchmarks of poll cq likely require including use of the data. The proposal is the equivalent of C++ accessor functions, which I admit I have never been a fan of, though the use seems simple enough. And I don't have a better proposal offhand. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
