Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2743 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]