On 4/20/2016 4:46 PM, Doug Ledford wrote: > On 04/19/2016 04:44 PM, Hefty, Sean wrote: >>> Right - and the RDMA uAPI has always had an integrated driver-bypass >>> channel as part of the verb uAPI calls, extending that to allow for >>> new-driver-specific calls seems very natural. >> >> I remain unconvinced that having the equivalent of: >> >> 1 open unrelated-interface >> 2 ioctl open-file >> 3 close unrelated-interface >> >> is desirable. If you want to push for a generic mechanism for mapping NIC resources into user space, then separate that from the device implementation. >> >> Doug, can you weigh in here with your thoughts? >> > > Yeah. I've been off working on issues related to 4.6-rc (interfaces > that are DOA). Give me a little bit to catch up on the thread and I'll > weigh in. > I've spent a decent amount of time thinking about this as well as the general questions posed in the "Furhter thoughts on uAPI" thread. In regards to the specific issues brought up here, and not really dealing with the concept of a Verbs 2.0 API. I've been seeing more and more instances where we need to implement something, but over and over again, it's already been done (albeit not necessarily to our needs) in the core net stack. It's actually so common that I'm starting to feel like I'm in the "Simpson's Did It" South Park episode. I toyed for a bit with the idea that we could alter the core RDMA stack to simply always allocate a netdevice and in some way transition the RDMA stack to being a more fully integrated member of the net stack. This does have some advantages, but also lots of difficulties. However, in retrospect, the iWARP, RoCE, and usNIC devices all already have netdevices because they are all Ethernet devices that support some form of RDMA. The only devices left out are OPA and IB. We already have precedent for requiring an IPoIB device, and it's associate netdevice, in order to manage some non-IP, non-Ethernet, IB specific items (the recent SRIOV patches being a perfect example). I think we simply need to standardize on this. As such, I think I want to make this a hard and fast rule: For those devices that aren't netdevices in their own right, management that can be done via their IPoIB device(s), should be done that way. The Ethernet devices already have their own EEPROM writing code, so I see no reason why we can't add an EEPROM read/write hook to IPoIB and then pass that on down to the hfi1 device. Unless people have objections to this as a way forward, Dennis, as much as possible, when you attempt to address the comments in this thread, please do so via the IPoIB devices and existing core net stack infrastructure.
Attachment:
signature.asc
Description: OpenPGP digital signature
