On Thu, May 05, 2016 at 11:21:29AM +0300, Matan Barak wrote: > >This should probably be done after creating the QP (and AH?), as a NIC > >may not be able to do certain LSO rules with certain QP/AH > >configurations. > > > > So I guess we want something that after a user creates a QP, he can query > which protocols (IP, TCP, etc) could be used in the NIC's segmentation > offload mechanism. This is where I get upset with the process we are following here, without input from other hardware architects in other companies, it is hard to design something truly common. > >I'd probably also use the driver-specific channel to communicate the > >NIC's capability and prototype some kind of API in libibverbs. > > If we would like to expose this feature in the uAPI, why would we want to > use the vendor specific channel instead of the standard core channel? Because we don't really know what we are doing, we have only one example of hardware that implements this and we can change libibverbs with alot less pain than changing the kernel's uAPI. If you use the driver channel, and are smart about it, you can generically expose everything the card can do and can stop churning the kernel every time a new QP feature comes up. How is that not better for everyone? When multiple vendors actually implement a verbs feature (or agree to implement one via IBTA/IETF/etc) then it becomes much safer to enshrine it forever in a common kernel uAPI. Jason -- 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
