> netlink is a reasonable low speed format to use for this kind of > serialization, > either via the common mux or via your own char device. >
A couple of follow-up netlink questions. 1. I assume you are talking about generic netlink vs. say the RDMA netlink. The generic netlink handles dynamic id assignment which would seem to make it a better choice. 2. Can you clarify "via your own char device"? I think netlink is char device independent. For PSM2, the mmap() overload is required for setting up direct hardware access, so we need the device. The difference here is that PSM[12] also uses aio/iter overload for bulk SDMA traffic. The use of write() as a control is consistent with the core. > I also wonder about all those sysfs files. I think the over reliance on sysfs > in > rdma may have been a mistake, sending the same information over netlink > would be more consistent with what netdev is doing. (eg you can't view the > netdev IP addresses via sysfs, but you can view rdma guids via sysfs) > The current sysfs usage is consistent with PSM1/qib use with updates for OPA differences. I will update the sysfs docs for both qib and wfr as part of the patch set. > Overall, I'd be alot happier with your driver patchset if it was split as > 'core > only, no UAPI changes' followed up by 'Add UAPI for X'. > > If you can't make a verbs provider work under 'core only' then I think > something is very wrong... > > UAPI stuff in drivers is often a red flag, and you guys should think really > carefully about what OPA elements should be buried in the driver and what > elements should be common to all OPA adapters. > By UAPI, do you mean the file in the include/uapi, the sysfs additions, the PSM side of the driver, or all these? Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
