diff mbox

[06/10] IB/hfi1: Add ioctl() interface for user commands

Message ID 20160519122622.22041.41686.stgit@scvm10.sc.intel.com (mailing list archive)
State Accepted
Headers show

Commit Message

Dennis Dalessandro May 19, 2016, 12:26 p.m. UTC
IOCTL is more suited to what user space commands need to do than the
write() interface. Add IOCTL definitions for all existing write commands
and the handling for those. The write() interface will be removed in a
follow on patch.

Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
---
 drivers/staging/rdma/hfi1/common.h   |    5 +
 drivers/staging/rdma/hfi1/file_ops.c |  204 ++++++++++++++++++++++++++++++++++
 include/uapi/rdma/hfi/hfi1_user.h    |   40 +++++++
 3 files changed, 248 insertions(+), 1 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Leon Romanovsky May 21, 2016, 12:34 p.m. UTC | #1
On Thu, May 19, 2016 at 05:26:24AM -0700, Dennis Dalessandro wrote:
> IOCTL is more suited to what user space commands need to do than the
> write() interface. Add IOCTL definitions for all existing write commands
> and the handling for those. The write() interface will be removed in a
> follow on patch.
> 
> Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
> Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
> ---
>  drivers/staging/rdma/hfi1/common.h   |    5 +
>  drivers/staging/rdma/hfi1/file_ops.c |  204 ++++++++++++++++++++++++++++++++++
>  include/uapi/rdma/hfi/hfi1_user.h    |   40 +++++++
>  3 files changed, 248 insertions(+), 1 deletions(-)
> 

<...>

> +#define IB_IOCTL_MAGIC 0x1b /* See Documentation/ioctl/ioctl-number.txt */
> +
> +struct hfi1_cmd;
> +#define HFI1_IOCTL_ASSIGN_CTXT \
> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_ASSIGN_CTXT, struct hfi1_user_info)
> +#define HFI1_IOCTL_CTXT_INFO \
> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_INFO, struct hfi1_ctxt_info)
> +#define HFI1_IOCTL_USER_INFO \
> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_USER_INFO, struct hfi1_base_info)
> +#define HFI1_IOCTL_TID_UPDATE \
> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_UPDATE, struct hfi1_tid_info)
> +#define HFI1_IOCTL_TID_FREE \
> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_FREE, struct hfi1_tid_info)
> +#define HFI1_IOCTL_CREDIT_UPD \
> +	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CREDIT_UPD)
> +#define HFI1_IOCTL_RECV_CTRL \
> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_RECV_CTRL, int)
> +#define HFI1_IOCTL_POLL_TYPE \
> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_POLL_TYPE, int)
> +#define HFI1_IOCTL_ACK_EVENT \
> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_ACK_EVENT, unsigned long)
> +#define HFI1_IOCTL_SET_PKEY \
> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_SET_PKEY, __u16)
> +#define HFI1_IOCTL_CTXT_RESET \
> +	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_RESET)
> +#define HFI1_IOCTL_TID_INVAL_READ \
> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_INVAL_READ, struct hfi1_tid_info)
> +#define HFI1_IOCTL_GET_VERS \
> +	_IOR(IB_IOCTL_MAGIC, HFI1_CMD_GET_VERS, int)
>  

I think the overall consensus over participants in OFVWG call was to use
one IOCTL to enter into device specific handler which will do all
necessary parsing and not spamming common IOCTL interface.
Dennis Dalessandro May 21, 2016, 4:23 p.m. UTC | #2
On Sat, May 21, 2016 at 03:34:04PM +0300, Leon Romanovsky wrote:
>On Thu, May 19, 2016 at 05:26:24AM -0700, Dennis Dalessandro wrote:
>> IOCTL is more suited to what user space commands need to do than the
>> write() interface. Add IOCTL definitions for all existing write commands
>> and the handling for those. The write() interface will be removed in a
>> follow on patch.
>> 
>> Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
>> Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
>> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
>> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
>> ---
>>  drivers/staging/rdma/hfi1/common.h   |    5 +
>>  drivers/staging/rdma/hfi1/file_ops.c |  204 ++++++++++++++++++++++++++++++++++
>>  include/uapi/rdma/hfi/hfi1_user.h    |   40 +++++++
>>  3 files changed, 248 insertions(+), 1 deletions(-)
>> 
>
><...>
>
>> +#define IB_IOCTL_MAGIC 0x1b /* See Documentation/ioctl/ioctl-number.txt */
>> +
>> +struct hfi1_cmd;
>> +#define HFI1_IOCTL_ASSIGN_CTXT \
>> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_ASSIGN_CTXT, struct hfi1_user_info)
>> +#define HFI1_IOCTL_CTXT_INFO \
>> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_INFO, struct hfi1_ctxt_info)
>> +#define HFI1_IOCTL_USER_INFO \
>> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_USER_INFO, struct hfi1_base_info)
>> +#define HFI1_IOCTL_TID_UPDATE \
>> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_UPDATE, struct hfi1_tid_info)
>> +#define HFI1_IOCTL_TID_FREE \
>> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_FREE, struct hfi1_tid_info)
>> +#define HFI1_IOCTL_CREDIT_UPD \
>> +	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CREDIT_UPD)
>> +#define HFI1_IOCTL_RECV_CTRL \
>> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_RECV_CTRL, int)
>> +#define HFI1_IOCTL_POLL_TYPE \
>> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_POLL_TYPE, int)
>> +#define HFI1_IOCTL_ACK_EVENT \
>> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_ACK_EVENT, unsigned long)
>> +#define HFI1_IOCTL_SET_PKEY \
>> +	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_SET_PKEY, __u16)
>> +#define HFI1_IOCTL_CTXT_RESET \
>> +	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_RESET)
>> +#define HFI1_IOCTL_TID_INVAL_READ \
>> +	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_INVAL_READ, struct hfi1_tid_info)
>> +#define HFI1_IOCTL_GET_VERS \
>> +	_IOR(IB_IOCTL_MAGIC, HFI1_CMD_GET_VERS, int)
>>  
>
>I think the overall consensus over participants in OFVWG call was to use
>one IOCTL to enter into device specific handler which will do all
>necessary parsing and not spamming common IOCTL interface.

That was for the verbs working group and the verbs 2.0 uAPI. This is for 
psm. We have some commands which are write or read only, and some which are  
read and write. It seems natural to classify their ioctl as such.

In the interim, while the OFVWG is solidifying its one API to rule them all, 
this solves our current and very specific problem of treating 
write()/writev() differently.  

-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Leon Romanovsky May 22, 2016, 12:01 p.m. UTC | #3
On Sat, May 21, 2016 at 12:23:02PM -0400, Dennis Dalessandro wrote:
> On Sat, May 21, 2016 at 03:34:04PM +0300, Leon Romanovsky wrote:
> >On Thu, May 19, 2016 at 05:26:24AM -0700, Dennis Dalessandro wrote:
> >>IOCTL is more suited to what user space commands need to do than the
> >>write() interface. Add IOCTL definitions for all existing write commands
> >>and the handling for those. The write() interface will be removed in a
> >>follow on patch.
> >>
> >>Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
> >>Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
> >>Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> >>Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
> >>---
> >> drivers/staging/rdma/hfi1/common.h   |    5 +
> >> drivers/staging/rdma/hfi1/file_ops.c |  204 ++++++++++++++++++++++++++++++++++
> >> include/uapi/rdma/hfi/hfi1_user.h    |   40 +++++++
> >> 3 files changed, 248 insertions(+), 1 deletions(-)
> >>
> >
> ><...>
> >
> >>+#define IB_IOCTL_MAGIC 0x1b /* See Documentation/ioctl/ioctl-number.txt */
> >>+
> >>+struct hfi1_cmd;
> >>+#define HFI1_IOCTL_ASSIGN_CTXT \
> >>+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_ASSIGN_CTXT, struct hfi1_user_info)
> >>+#define HFI1_IOCTL_CTXT_INFO \
> >>+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_INFO, struct hfi1_ctxt_info)
> >>+#define HFI1_IOCTL_USER_INFO \
> >>+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_USER_INFO, struct hfi1_base_info)
> >>+#define HFI1_IOCTL_TID_UPDATE \
> >>+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_UPDATE, struct hfi1_tid_info)
> >>+#define HFI1_IOCTL_TID_FREE \
> >>+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_FREE, struct hfi1_tid_info)
> >>+#define HFI1_IOCTL_CREDIT_UPD \
> >>+	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CREDIT_UPD)
> >>+#define HFI1_IOCTL_RECV_CTRL \
> >>+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_RECV_CTRL, int)
> >>+#define HFI1_IOCTL_POLL_TYPE \
> >>+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_POLL_TYPE, int)
> >>+#define HFI1_IOCTL_ACK_EVENT \
> >>+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_ACK_EVENT, unsigned long)
> >>+#define HFI1_IOCTL_SET_PKEY \
> >>+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_SET_PKEY, __u16)
> >>+#define HFI1_IOCTL_CTXT_RESET \
> >>+	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_RESET)
> >>+#define HFI1_IOCTL_TID_INVAL_READ \
> >>+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_INVAL_READ, struct hfi1_tid_info)
> >>+#define HFI1_IOCTL_GET_VERS \
> >>+	_IOR(IB_IOCTL_MAGIC, HFI1_CMD_GET_VERS, int)
> >
> >I think the overall consensus over participants in OFVWG call was to use
> >one IOCTL to enter into device specific handler which will do all
> >necessary parsing and not spamming common IOCTL interface.
> 
> That was for the verbs working group and the verbs 2.0 uAPI. This is for
> psm.

I'm glad that you are supporting my point.
It is vendor specific implementation for vendor specific driver and not
for whole IB core, so there is no need to pollute general IB ioctls.

> In the interim, while the OFVWG is solidifying its one API to rule them all,
> this solves our current and very specific problem of treating
> write()/writev() differently.

OFVWG is working on improving current verbs interface, for proprietary things like this,
there is agreed API which will look similar to this:

1051 static long ib_uverbs_ioctl(struct file *filp, unsigned int cmd,
1052                                 unsigned long arg)
1053 {
1054         struct ib_uverbs_ioctl_hdr __user *user_hdr =
1055                 (struct ib_uverbs_ioctl_hdr __user *)arg;
1056         struct ib_uverbs_ioctl_hdr hdr;
1057
1058         struct ib_uverbs_file *file = filp->private_data;
1059         struct ib_device *ib_dev;
1060         int srcu_key;
1061         long ret = 0;
1062
1063         if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
1064                 return -EACCES;
1065
1066         if (cmd == IB_USER_DIRECT_IOCTL_COMMAND) {
1067                 srcu_key = srcu_read_lock(&file->device->disassociate_srcu);
1068                 ib_dev = srcu_dereference(file->device->ib_dev,
1069						&file->device->disassociate_srcu);
1070                 if (!ib_dev) {
1071			     srcu_read_unlock(&file->device->disassociate_srcu, srcu_key);
1072                         return -EIO;
1073                 }
1074
1075                 if (ib_dev->direct_fn)
1076                         ret = ib_dev->direct_fn(filp, arg);
1077
1078                 srcu_read_unlock(&file->device->disassociate_srcu,srcu_key);
1079                 return ret;

> 
> -Denny
Dennis Dalessandro May 22, 2016, 2:03 p.m. UTC | #4
On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
>> >I think the overall consensus over participants in OFVWG call was to use
>> >one IOCTL to enter into device specific handler which will do all
>> >necessary parsing and not spamming common IOCTL interface.
>> 
>> That was for the verbs working group and the verbs 2.0 uAPI. This is for
>> psm.
>
>I'm glad that you are supporting my point.
>It is vendor specific implementation for vendor specific driver and not
>for whole IB core, so there is no need to pollute general IB ioctls.

It is making use of and applying a proper classification.  Is there a 
technical concern with this other than that's not how verbs may end up doing 
it? 

I'm not completely opposed to the single ioctl, I just don't necessarily see 
that as better in this case but am willing to listen to a technical 
justification for why it's incorrect.

>> In the interim, while the OFVWG is solidifying its one API to rule them 
>> all,
>> this solves our current and very specific problem of treating
>> write()/writev() differently.
>
>OFVWG is working on improving current verbs interface, for proprietary things like this,
>there is agreed API which will look similar to this:

As far as I know there has been no patches posted or real on-list review of 
this API as of yet.

-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Leon Romanovsky May 22, 2016, 5:57 p.m. UTC | #5
On Sun, May 22, 2016 at 10:03:52AM -0400, Dennis Dalessandro wrote:
> On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
> >>>I think the overall consensus over participants in OFVWG call was to use
> >>>one IOCTL to enter into device specific handler which will do all
> >>>necessary parsing and not spamming common IOCTL interface.
> >>
> >>That was for the verbs working group and the verbs 2.0 uAPI. This is for
> >>psm.
> >
> >I'm glad that you are supporting my point.
> >It is vendor specific implementation for vendor specific driver and not
> >for whole IB core, so there is no need to pollute general IB ioctls.
> 
> It is making use of and applying a proper classification.  Is there a
> technical concern with this other than that's not how verbs may end up doing
> it?
> 
> I'm not completely opposed to the single ioctl, I just don't necessarily see
> that as better in this case but am willing to listen to a technical
> justification for why it's incorrect.

it will simplify internal and external development by removing the
tensions over ioctls numbers. Do you plan to take the block of ioctls
for future expansion? Do you plan to mix hfi's ioctls with verbs's ioctls
based on acceptance of new code?

> 
> >>In the interim, while the OFVWG is solidifying its one API to rule them
> >>all,
> >>this solves our current and very specific problem of treating
> >>write()/writev() differently.
> >
> >OFVWG is working on improving current verbs interface, for proprietary things like this,
> >there is agreed API which will look similar to this:
> 
> As far as I know there has been no patches posted or real on-list review of
> this API as of yet.

Right.

> 
> -Denny
Dennis Dalessandro May 23, 2016, 12:22 p.m. UTC | #6
On Sun, May 22, 2016 at 08:57:15PM +0300, Leon Romanovsky wrote:
>On Sun, May 22, 2016 at 10:03:52AM -0400, Dennis Dalessandro wrote:
>> On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
>> >>>I think the overall consensus over participants in OFVWG call was to use
>> >>>one IOCTL to enter into device specific handler which will do all
>> >>>necessary parsing and not spamming common IOCTL interface.
>> >>
>> >>That was for the verbs working group and the verbs 2.0 uAPI. This is for
>> >>psm.
>> >
>> >I'm glad that you are supporting my point.
>> >It is vendor specific implementation for vendor specific driver and not
>> >for whole IB core, so there is no need to pollute general IB ioctls.
>> 
>> It is making use of and applying a proper classification.  Is there a
>> technical concern with this other than that's not how verbs may end up doing
>> it?
>> 
>> I'm not completely opposed to the single ioctl, I just don't necessarily see
>> that as better in this case but am willing to listen to a technical
>> justification for why it's incorrect.
>
>it will simplify internal and external development by removing the
>tensions over ioctls numbers. Do you plan to take the block of ioctls
>for future expansion? Do you plan to mix hfi's ioctls with verbs's ioctls
>based on acceptance of new code?

I'm still not sure what you are getting at here. Can you explain what you 
mean by tensions over ioctl numbers?  I guess I don't understand why the 
hfi1_x device's use of icotl numbers has any bearing at all on the 
ibcore/verbs ioctl(s). 

If and when new code is accepted and hfi1 converges its API to go through a 
common character device, then hfi1 would surely change to match whatever is 
there whether that's a single ioctl with a command type embedded or 
something that has not even yet been proposed.

-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Leon Romanovsky May 23, 2016, 1:03 p.m. UTC | #7
On Mon, May 23, 2016 at 08:22:08AM -0400, Dennis Dalessandro wrote:
> On Sun, May 22, 2016 at 08:57:15PM +0300, Leon Romanovsky wrote:
> >On Sun, May 22, 2016 at 10:03:52AM -0400, Dennis Dalessandro wrote:
> >>On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
> >>>>>I think the overall consensus over participants in OFVWG call was to use
> >>>>>one IOCTL to enter into device specific handler which will do all
> >>>>>necessary parsing and not spamming common IOCTL interface.
> >>>>
> >>>>That was for the verbs working group and the verbs 2.0 uAPI. This is for
> >>>>psm.
> >>>
> >>>I'm glad that you are supporting my point.
> >>>It is vendor specific implementation for vendor specific driver and not
> >>>for whole IB core, so there is no need to pollute general IB ioctls.
> >>
> >>It is making use of and applying a proper classification.  Is there a
> >>technical concern with this other than that's not how verbs may end up doing
> >>it?
> >>
> >>I'm not completely opposed to the single ioctl, I just don't necessarily see
> >>that as better in this case but am willing to listen to a technical
> >>justification for why it's incorrect.
> >
> >it will simplify internal and external development by removing the
> >tensions over ioctls numbers. Do you plan to take the block of ioctls
> >for future expansion? Do you plan to mix hfi's ioctls with verbs's ioctls
> >based on acceptance of new code?
> 
> I'm still not sure what you are getting at here. Can you explain what you
> mean by tensions over ioctl numbers?  I guess I don't understand why the
> hfi1_x device's use of icotl numbers has any bearing at all on the
> ibcore/verbs ioctl(s).
> 
> If and when new code is accepted and hfi1 converges its API to go through a
> common character device, then hfi1 would surely change to match whatever is
> there whether that's a single ioctl with a command type embedded or
> something that has not even yet been proposed.

Denny,

It is easy for everyone to converge hfi1 API from day one, so if and
when new code is posted, the hfi1 changes will be summarized by one
line change.

Thanks.

> 
> -Denny
Dennis Dalessandro May 23, 2016, 2:10 p.m. UTC | #8
On Mon, May 23, 2016 at 04:03:12PM +0300, Leon Romanovsky wrote:
>On Mon, May 23, 2016 at 08:22:08AM -0400, Dennis Dalessandro wrote:
>> On Sun, May 22, 2016 at 08:57:15PM +0300, Leon Romanovsky wrote:
>> >On Sun, May 22, 2016 at 10:03:52AM -0400, Dennis Dalessandro wrote:
>> >>On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
>> >>>>>I think the overall consensus over participants in OFVWG call was to use
>> >>>>>one IOCTL to enter into device specific handler which will do all
>> >>>>>necessary parsing and not spamming common IOCTL interface.
>> >>>>
>> >>>>That was for the verbs working group and the verbs 2.0 uAPI. This is for
>> >>>>psm.
>> >>>
>> >>>I'm glad that you are supporting my point.
>> >>>It is vendor specific implementation for vendor specific driver and not
>> >>>for whole IB core, so there is no need to pollute general IB ioctls.
>> >>
>> >>It is making use of and applying a proper classification.  Is there a
>> >>technical concern with this other than that's not how verbs may end up doing
>> >>it?
>> >>
>> >>I'm not completely opposed to the single ioctl, I just don't necessarily see
>> >>that as better in this case but am willing to listen to a technical
>> >>justification for why it's incorrect.
>> >
>> >it will simplify internal and external development by removing the
>> >tensions over ioctls numbers. Do you plan to take the block of ioctls
>> >for future expansion? Do you plan to mix hfi's ioctls with verbs's ioctls
>> >based on acceptance of new code?
>> 
>> I'm still not sure what you are getting at here. Can you explain what you
>> mean by tensions over ioctl numbers?  I guess I don't understand why the
>> hfi1_x device's use of icotl numbers has any bearing at all on the
>> ibcore/verbs ioctl(s).
>> 
>> If and when new code is accepted and hfi1 converges its API to go through a
>> common character device, then hfi1 would surely change to match whatever is
>> there whether that's a single ioctl with a command type embedded or
>> something that has not even yet been proposed.
>
>Denny,
>
>It is easy for everyone to converge hfi1 API from day one, so if and
>when new code is posted, the hfi1 changes will be summarized by one
>line change.

Let's put the future API issue, and the specifics of this patch aside for 
just a minute.  I'd like to understand the rationale for wanting a single 
ioctl over specific ioctls in the general sense. I know that's what folks 
seem to prefer from the calls, but perhaps we can get that down in writing 
here on the list.

I see an advantage for the specific ioctls because we can classify them 
based on permission. When running things like strace you can decode the 
ioctl number and see what access it is making. It also makes it easy to have 
a gist of what is going on based on the ioctl call itself.

On the other hand, having a bunch of ioctls may make it harder on user 
space. A well known ioctl may make life easier. I'm assuming there are other 
compelling reasons?

-Denny


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jason Gunthorpe May 24, 2016, 5:14 p.m. UTC | #9
On Mon, May 23, 2016 at 10:10:50AM -0400, Dennis Dalessandro wrote:

> ioctl over specific ioctls in the general sense. I know that's what folks
> seem to prefer from the calls, but perhaps we can get that down in writing
> here on the list.

The ioctl space is quite limited, based on # alone there is something
like 256 of them available within 0x1b. This is not enough for all the
calls that uverbs needs, so they must be multiplexed. Once we start
multiplexing we may as well multiplex everything.

It is desired in the kernel, in general, that ioctls are globally
unique. If hfi1 uses an ioctl number it becomes unavailable to other
parts of the kernel, including verbs. You also need to check you are
not re-using any of these ioctl numbers between other ib things like
umad/etc.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Doug Ledford May 24, 2016, 7:17 p.m. UTC | #10
On 05/24/2016 01:54 PM, Leon Romanovsky wrote:
> On Tue, May 24, 2016 at 12:13:56PM -0400, Doug Ledford wrote:
>> On 05/23/2016 10:10 AM, Dennis Dalessandro wrote:
>>> On Mon, May 23, 2016 at 04:03:12PM +0300, Leon Romanovsky wrote:
>>>> On Mon, May 23, 2016 at 08:22:08AM -0400, Dennis Dalessandro wrote:
>>>>> On Sun, May 22, 2016 at 08:57:15PM +0300, Leon Romanovsky wrote:
>>>>>> On Sun, May 22, 2016 at 10:03:52AM -0400, Dennis Dalessandro wrote:
>>>>>>> On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
>>>>>>>>>> I think the overall consensus over participants in OFVWG call
>>>>> was to use
>>>>>>>>>> one IOCTL to enter into device specific handler which will do all
>>>>>>>>>> necessary parsing and not spamming common IOCTL interface.
>>>>>>>>>
>>>>>>>>> That was for the verbs working group and the verbs 2.0 uAPI. This
>>>>> is for
>>>>>>>>> psm.
>>>>>>>>
>>>>>>>> I'm glad that you are supporting my point.
>>>>>>>> It is vendor specific implementation for vendor specific driver
>>>>> and not
>>>>>>>> for whole IB core, so there is no need to pollute general IB ioctls.
>>>>>>>
>>>>>>> It is making use of and applying a proper classification.  Is there a
>>>>>>> technical concern with this other than that's not how verbs may end
>>>>> up doing
>>>>>>> it?
>>>>>>>
>>>>>>> I'm not completely opposed to the single ioctl, I just don't
>>>>> necessarily see
>>>>>>> that as better in this case but am willing to listen to a technical
>>>>>>> justification for why it's incorrect.
>>>>>>
>>>>>> it will simplify internal and external development by removing the
>>>>>> tensions over ioctls numbers. Do you plan to take the block of ioctls
>>>>>> for future expansion? Do you plan to mix hfi's ioctls with verbs's
>>>>> ioctls
>>>>>> based on acceptance of new code?
>>>>>
>>>>> I'm still not sure what you are getting at here. Can you explain what
>>>>> you
>>>>> mean by tensions over ioctl numbers?  I guess I don't understand why the
>>>>> hfi1_x device's use of icotl numbers has any bearing at all on the
>>>>> ibcore/verbs ioctl(s).
>>>>>
>>>>> If and when new code is accepted and hfi1 converges its API to go
>>>>> through a
>>>>> common character device, then hfi1 would surely change to match
>>>>> whatever is
>>>>> there whether that's a single ioctl with a command type embedded or
>>>>> something that has not even yet been proposed.
>>>>
>>>> Denny,
>>>>
>>>> It is easy for everyone to converge hfi1 API from day one, so if and
>>>> when new code is posted, the hfi1 changes will be summarized by one
>>>> line change.
>>>
>>> Let's put the future API issue, and the specifics of this patch aside
>>> for just a minute.  I'd like to understand the rationale for wanting a
>>> single ioctl over specific ioctls in the general sense. I know that's
>>> what folks seem to prefer from the calls, but perhaps we can get that
>>> down in writing here on the list.
>>>
>>> I see an advantage for the specific ioctls because we can classify them
>>> based on permission. When running things like strace you can decode the
>>> ioctl number and see what access it is making. It also makes it easy to
>>> have a gist of what is going on based on the ioctl call itself.
>>
>> Personally, if there is no shortage of ioctls (and there shouldn't be in
>> this case because this is ioctls on the psm cdev, not on the uverbs
>> device file), then the separate ioctls have their benefits as Dennis
>> points out.  And seeing as how they (Intel) maintain the psm library
>> that uses this interface, if they want their library using different
>> ioctls and their driver using different ioctls versus one mega ioctl
>> with embedded commands, I'm inclined to let them decide how they want it
>> to be.
> 
> Except one thing that their device should integrate into already
> available char device and don't create new one in IB space.

They have always had their own device.  Until the verbs 2.0 API is moved
forward, I expect them to continue to do so.  That they used the
InfiniBand ioctl number means we might need to make sure that the verbs
2.0 API ioctl numbers and the ones they used don't clash, but given that
we have an assigned range of 256 ioctls and this patchset uses up only
13 (and 13 that could probably be shared with qib), I don't see this as
a starvation of ioctl space issue.
Leon Romanovsky May 24, 2016, 8:13 p.m. UTC | #11
On Tue, May 24, 2016 at 03:17:00PM -0400, Doug Ledford wrote:
> On 05/24/2016 01:54 PM, Leon Romanovsky wrote:
> > On Tue, May 24, 2016 at 12:13:56PM -0400, Doug Ledford wrote:
> >> On 05/23/2016 10:10 AM, Dennis Dalessandro wrote:
> >>> On Mon, May 23, 2016 at 04:03:12PM +0300, Leon Romanovsky wrote:
> >>>> On Mon, May 23, 2016 at 08:22:08AM -0400, Dennis Dalessandro wrote:
> >>>>> On Sun, May 22, 2016 at 08:57:15PM +0300, Leon Romanovsky wrote:
> >>>>>> On Sun, May 22, 2016 at 10:03:52AM -0400, Dennis Dalessandro wrote:
> >>>>>>> On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
> >>>>>>>>>> I think the overall consensus over participants in OFVWG call
> >>>>> was to use
> >>>>>>>>>> one IOCTL to enter into device specific handler which will do all
> >>>>>>>>>> necessary parsing and not spamming common IOCTL interface.
> >>>>>>>>>
> >>>>>>>>> That was for the verbs working group and the verbs 2.0 uAPI. This
> >>>>> is for
> >>>>>>>>> psm.
> >>>>>>>>
> >>>>>>>> I'm glad that you are supporting my point.
> >>>>>>>> It is vendor specific implementation for vendor specific driver
> >>>>> and not
> >>>>>>>> for whole IB core, so there is no need to pollute general IB ioctls.
> >>>>>>>
> >>>>>>> It is making use of and applying a proper classification.  Is there a
> >>>>>>> technical concern with this other than that's not how verbs may end
> >>>>> up doing
> >>>>>>> it?
> >>>>>>>
> >>>>>>> I'm not completely opposed to the single ioctl, I just don't
> >>>>> necessarily see
> >>>>>>> that as better in this case but am willing to listen to a technical
> >>>>>>> justification for why it's incorrect.
> >>>>>>
> >>>>>> it will simplify internal and external development by removing the
> >>>>>> tensions over ioctls numbers. Do you plan to take the block of ioctls
> >>>>>> for future expansion? Do you plan to mix hfi's ioctls with verbs's
> >>>>> ioctls
> >>>>>> based on acceptance of new code?
> >>>>>
> >>>>> I'm still not sure what you are getting at here. Can you explain what
> >>>>> you
> >>>>> mean by tensions over ioctl numbers?  I guess I don't understand why the
> >>>>> hfi1_x device's use of icotl numbers has any bearing at all on the
> >>>>> ibcore/verbs ioctl(s).
> >>>>>
> >>>>> If and when new code is accepted and hfi1 converges its API to go
> >>>>> through a
> >>>>> common character device, then hfi1 would surely change to match
> >>>>> whatever is
> >>>>> there whether that's a single ioctl with a command type embedded or
> >>>>> something that has not even yet been proposed.
> >>>>
> >>>> Denny,
> >>>>
> >>>> It is easy for everyone to converge hfi1 API from day one, so if and
> >>>> when new code is posted, the hfi1 changes will be summarized by one
> >>>> line change.
> >>>
> >>> Let's put the future API issue, and the specifics of this patch aside
> >>> for just a minute.  I'd like to understand the rationale for wanting a
> >>> single ioctl over specific ioctls in the general sense. I know that's
> >>> what folks seem to prefer from the calls, but perhaps we can get that
> >>> down in writing here on the list.
> >>>
> >>> I see an advantage for the specific ioctls because we can classify them
> >>> based on permission. When running things like strace you can decode the
> >>> ioctl number and see what access it is making. It also makes it easy to
> >>> have a gist of what is going on based on the ioctl call itself.
> >>
> >> Personally, if there is no shortage of ioctls (and there shouldn't be in
> >> this case because this is ioctls on the psm cdev, not on the uverbs
> >> device file), then the separate ioctls have their benefits as Dennis
> >> points out.  And seeing as how they (Intel) maintain the psm library
> >> that uses this interface, if they want their library using different
> >> ioctls and their driver using different ioctls versus one mega ioctl
> >> with embedded commands, I'm inclined to let them decide how they want it
> >> to be.
> > 
> > Except one thing that their device should integrate into already
> > available char device and don't create new one in IB space.
> 
> They have always had their own device.  Until the verbs 2.0 API is moved
> forward, I expect them to continue to do so.  That they used the
> InfiniBand ioctl number means we might need to make sure that the verbs
> 2.0 API ioctl numbers and the ones they used don't clash, but given that
> we have an assigned range of 256 ioctls and this patchset uses up only
> 13 (and 13 that could probably be shared with qib), I don't see this as
> a starvation of ioctl space issue.

Let's assume that you are planning to provide block of 20 ioctls per
device. Right now, there are 10 (or 8 if we count driver families) drivers in
drivers/infiniband/hw/ + 1 is coming (HSI) + uverbs (approximately 40)
=> 8 * 20 + 20 + 40 = 220 ioctls => we already in shortage without room
to expansion.

Why do we need to put ourselves in such situation?

> 
> 
> -- 
> Doug Ledford <dledford@redhat.com>
>               GPG KeyID: 0E572FDD
> 
>
Hefty, Sean May 24, 2016, 8:29 p.m. UTC | #12
> Let's assume that you are planning to provide block of 20 ioctls per
> device. Right now, there are 10 (or 8 if we count driver families) drivers in
> drivers/infiniband/hw/ + 1 is coming (HSI) + uverbs (approximately 40)
> => 8 * 20 + 20 + 40 = 220 ioctls => we already in shortage without room
> to expansion.

Ioctl commands are naturally scoped per open file.  Unless the opened file supports ioctls directed to every piece of hardware, I don't see why there's an obsession with command space.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jason Gunthorpe May 24, 2016, 8:54 p.m. UTC | #13
On Tue, May 24, 2016 at 08:29:41PM +0000, Hefty, Sean wrote:
> > Let's assume that you are planning to provide block of 20 ioctls per
> > device. Right now, there are 10 (or 8 if we count driver families) drivers in
> > drivers/infiniband/hw/ + 1 is coming (HSI) + uverbs (approximately 40)
> > => 8 * 20 + 20 + 40 = 220 ioctls => we already in shortage without room
> > to expansion.
> 
> Ioctl commands are naturally scoped per open file.  Unless the
> opened file supports ioctls directed to every piece of hardware, I
> don't see why there's an obsession with command space.

The kernel standard is to have ioctl numbers be globally unique, even
though technically you are right and they are scoped to a file.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hefty, Sean May 24, 2016, 10:08 p.m. UTC | #14
> > Ioctl commands are naturally scoped per open file.  Unless the
> > opened file supports ioctls directed to every piece of hardware, I
> > don't see why there's an obsession with command space.
> 
> The kernel standard is to have ioctl numbers be globally unique, even
> though technically you are right and they are scoped to a file.

I thought the reason behind that was so that an app that sent an ioctl to the wrong file would get an error, rather than unspecified behavior.  If so, collapsing all ioctls to a single command doesn't really solve the issue.  It's kind of like using a write interface instead of an ioctl interface to avoid using ioctls.  :)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jason Gunthorpe May 24, 2016, 10:15 p.m. UTC | #15
On Tue, May 24, 2016 at 10:08:10PM +0000, Hefty, Sean wrote:
> > > Ioctl commands are naturally scoped per open file.  Unless the
> > > opened file supports ioctls directed to every piece of hardware, I
> > > don't see why there's an obsession with command space.
> > 
> > The kernel standard is to have ioctl numbers be globally unique, even
> > though technically you are right and they are scoped to a file.
> 
> I thought the reason behind that was so that an app that sent an
> ioctl to the wrong file would get an error, rather than unspecified
> behavior.

Yes, that is an oft quoted reason, but it also allows strace to decode
all the ioctls.

> If so, collapsing all ioctls to a single command doesn't
> really solve the issue.  It's kind of like using a write interface
> instead of an ioctl interface to avoid using ioctls.  :)

The idea isn't to collapse, but to expand the decode to include some
data from the header. Instead of just dispatching on the ioctl, you
dispatch on the (ioctl,domain,command) tuple. In your patches domain
is encoded in the header, in Leon's domain & command are encoded in
the header. Doesn't really matter.

At the end of the day the decode is globally unique and does not
require scoping to the open'd file to understand.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Doug Ledford May 25, 2016, 5:56 p.m. UTC | #16
On 05/24/2016 04:54 PM, Jason Gunthorpe wrote:
> On Tue, May 24, 2016 at 08:29:41PM +0000, Hefty, Sean wrote:
>>> Let's assume that you are planning to provide block of 20 ioctls per
>>> device. Right now, there are 10 (or 8 if we count driver families) drivers in
>>> drivers/infiniband/hw/ + 1 is coming (HSI) + uverbs (approximately 40)
>>> => 8 * 20 + 20 + 40 = 220 ioctls => we already in shortage without room
>>> to expansion.
>>
>> Ioctl commands are naturally scoped per open file.  Unless the
>> opened file supports ioctls directed to every piece of hardware, I
>> don't see why there's an obsession with command space.
> 
> The kernel standard is to have ioctl numbers be globally unique, even
> though technically you are right and they are scoped to a file.

A not very well followed standard...
Doug Ledford May 26, 2016, 4:08 p.m. UTC | #17
On 05/25/2016 01:56 PM, Doug Ledford wrote:
> On 05/24/2016 04:54 PM, Jason Gunthorpe wrote:
>> On Tue, May 24, 2016 at 08:29:41PM +0000, Hefty, Sean wrote:
>>>> Let's assume that you are planning to provide block of 20 ioctls per
>>>> device. Right now, there are 10 (or 8 if we count driver families) drivers in
>>>> drivers/infiniband/hw/ + 1 is coming (HSI) + uverbs (approximately 40)
>>>> => 8 * 20 + 20 + 40 = 220 ioctls => we already in shortage without room
>>>> to expansion.
>>>
>>> Ioctl commands are naturally scoped per open file.  Unless the
>>> opened file supports ioctls directed to every piece of hardware, I
>>> don't see why there's an obsession with command space.
>>
>> The kernel standard is to have ioctl numbers be globally unique, even
>> though technically you are right and they are scoped to a file.
> 
> A not very well followed standard...
> 
> 

I took this patch, but I moved all of your ioctl numbers to the end of
the range by doing this to your declarations:

/*
 * Make the ioctls occupy the last 0xf0-0xff portion of the IB range
 */
#define __NUM(cmd) (HFI1_CMD_##cmd + 0xe0)

struct hfi1_cmd;
#define HFI1_IOCTL_ASSIGN_CTXT \
        _IOWR(IB_IOCTL_MAGIC, __NUM(ASSIGN_CTXT), struct hfi1_user_info)
...

The intent here is that strace or other tools should be able to decode
the IB ioctls.  Since we are starting at the low end, it would be a
*long* time before we would ever get up here (if we even do).  Between
then and now, these will go away to be replaced by the vendor channel
support or something similar from verbs 2.0.  So I don't really care if
strace ever decodes these until we get official ioctls for the IB stack
at this location, and by then it doesn't need to know these ever existed
as they will be long gone.
diff mbox

Patch

diff --git a/drivers/staging/rdma/hfi1/common.h b/drivers/staging/rdma/hfi1/common.h
index e9b6bb3..fcc9c21 100644
--- a/drivers/staging/rdma/hfi1/common.h
+++ b/drivers/staging/rdma/hfi1/common.h
@@ -178,7 +178,8 @@ 
 		     HFI1_CAP_PKEY_CHECK |		\
 		     HFI1_CAP_NO_INTEGRITY)
 
-#define HFI1_USER_SWVERSION ((HFI1_USER_SWMAJOR << 16) | HFI1_USER_SWMINOR)
+#define HFI1_USER_SWVERSION ((HFI1_USER_SWMAJOR << HFI1_SWMAJOR_SHIFT) | \
+			     HFI1_USER_SWMINOR)
 
 #ifndef HFI1_KERN_TYPE
 #define HFI1_KERN_TYPE 0
@@ -349,6 +350,8 @@  struct hfi1_message_header {
 #define HFI1_BECN_MASK 1
 #define HFI1_BECN_SMASK BIT(HFI1_BECN_SHIFT)
 
+#define HFI1_PSM_IOC_BASE_SEQ 0x0
+
 static inline __u64 rhf_to_cpu(const __le32 *rbuf)
 {
 	return __le64_to_cpu(*((__le64 *)rbuf));
diff --git a/drivers/staging/rdma/hfi1/file_ops.c b/drivers/staging/rdma/hfi1/file_ops.c
index 322e55f..a338238 100644
--- a/drivers/staging/rdma/hfi1/file_ops.c
+++ b/drivers/staging/rdma/hfi1/file_ops.c
@@ -96,6 +96,8 @@  static int user_event_ack(struct hfi1_ctxtdata *, int, unsigned long);
 static int set_ctxt_pkey(struct hfi1_ctxtdata *, unsigned, u16);
 static int manage_rcvq(struct hfi1_ctxtdata *, unsigned, int);
 static int vma_fault(struct vm_area_struct *, struct vm_fault *);
+static long hfi1_file_ioctl(struct file *fp, unsigned int cmd,
+			    unsigned long arg);
 
 static const struct file_operations hfi1_file_ops = {
 	.owner = THIS_MODULE,
@@ -103,6 +105,7 @@  static const struct file_operations hfi1_file_ops = {
 	.write_iter = hfi1_write_iter,
 	.open = hfi1_file_open,
 	.release = hfi1_file_close,
+	.unlocked_ioctl = hfi1_file_ioctl,
 	.poll = hfi1_poll,
 	.mmap = hfi1_file_mmap,
 	.llseek = noop_llseek,
@@ -175,6 +178,207 @@  static int hfi1_file_open(struct inode *inode, struct file *fp)
 	return fp->private_data ? 0 : -ENOMEM;
 }
 
+static long hfi1_file_ioctl(struct file *fp, unsigned int cmd,
+			    unsigned long arg)
+{
+	struct hfi1_filedata *fd = fp->private_data;
+	struct hfi1_ctxtdata *uctxt = fd->uctxt;
+	struct hfi1_user_info uinfo;
+	struct hfi1_tid_info tinfo;
+	int ret = 0;
+	unsigned long addr;
+	int uval = 0;
+	unsigned long ul_uval = 0;
+	u16 uval16 = 0;
+
+	if (cmd != HFI1_IOCTL_ASSIGN_CTXT &&
+	    cmd != HFI1_IOCTL_GET_VERS &&
+	    !uctxt)
+		return -EINVAL;
+
+	switch (cmd) {
+	case HFI1_IOCTL_ASSIGN_CTXT:
+		if (copy_from_user(&uinfo,
+				   (struct hfi1_user_info __user *)arg,
+				   sizeof(uinfo)))
+			return -EFAULT;
+
+		ret = assign_ctxt(fp, &uinfo);
+		if (ret < 0)
+			return ret;
+		setup_ctxt(fp);
+		if (ret)
+			return ret;
+		ret = user_init(fp);
+		break;
+	case HFI1_IOCTL_CTXT_INFO:
+		ret = get_ctxt_info(fp, (void __user *)(unsigned long)arg,
+				    sizeof(struct hfi1_ctxt_info));
+		break;
+	case HFI1_IOCTL_USER_INFO:
+		ret = get_base_info(fp, (void __user *)(unsigned long)arg,
+				    sizeof(struct hfi1_base_info));
+		break;
+	case HFI1_IOCTL_CREDIT_UPD:
+		if (uctxt && uctxt->sc)
+			sc_return_credits(uctxt->sc);
+		break;
+
+	case HFI1_IOCTL_TID_UPDATE:
+		if (copy_from_user(&tinfo,
+				   (struct hfi11_tid_info __user *)arg,
+				   sizeof(tinfo)))
+			return -EFAULT;
+
+		ret = hfi1_user_exp_rcv_setup(fp, &tinfo);
+		if (!ret) {
+			/*
+			 * Copy the number of tidlist entries we used
+			 * and the length of the buffer we registered.
+			 * These fields are adjacent in the structure so
+			 * we can copy them at the same time.
+			 */
+			addr = arg + offsetof(struct hfi1_tid_info, tidcnt);
+			if (copy_to_user((void __user *)addr, &tinfo.tidcnt,
+					 sizeof(tinfo.tidcnt) +
+					 sizeof(tinfo.length)))
+				ret = -EFAULT;
+		}
+		break;
+
+	case HFI1_IOCTL_TID_FREE:
+		if (copy_from_user(&tinfo,
+				   (struct hfi11_tid_info __user *)arg,
+				   sizeof(tinfo)))
+			return -EFAULT;
+
+		ret = hfi1_user_exp_rcv_clear(fp, &tinfo);
+		if (ret)
+			break;
+		addr = arg + offsetof(struct hfi1_tid_info, tidcnt);
+		if (copy_to_user((void __user *)addr, &tinfo.tidcnt,
+				 sizeof(tinfo.tidcnt)))
+			ret = -EFAULT;
+		break;
+
+	case HFI1_IOCTL_TID_INVAL_READ:
+		if (copy_from_user(&tinfo,
+				   (struct hfi11_tid_info __user *)arg,
+				   sizeof(tinfo)))
+			return -EFAULT;
+
+		ret = hfi1_user_exp_rcv_invalid(fp, &tinfo);
+		if (ret)
+			break;
+		addr = arg + offsetof(struct hfi1_tid_info, tidcnt);
+		if (copy_to_user((void __user *)addr, &tinfo.tidcnt,
+				 sizeof(tinfo.tidcnt)))
+			ret = -EFAULT;
+		break;
+
+	case HFI1_IOCTL_RECV_CTRL:
+		ret = get_user(uval, (int __user *)arg);
+		if (ret != 0)
+			return -EFAULT;
+		ret = manage_rcvq(uctxt, fd->subctxt, uval);
+		break;
+
+	case HFI1_IOCTL_POLL_TYPE:
+		ret = get_user(uval, (int __user *)arg);
+		if (ret != 0)
+			return -EFAULT;
+		uctxt->poll_type = (typeof(uctxt->poll_type))uval;
+		break;
+
+	case HFI1_IOCTL_ACK_EVENT:
+		ret = get_user(ul_uval, (unsigned long __user *)arg);
+		if (ret != 0)
+			return -EFAULT;
+		ret = user_event_ack(uctxt, fd->subctxt, ul_uval);
+		break;
+
+	case HFI1_IOCTL_SET_PKEY:
+		ret = get_user(uval16, (u16 __user *)arg);
+		if (ret != 0)
+			return -EFAULT;
+		if (HFI1_CAP_IS_USET(PKEY_CHECK))
+			ret = set_ctxt_pkey(uctxt, fd->subctxt, uval16);
+		else
+			return -EPERM;
+		break;
+
+	case HFI1_IOCTL_CTXT_RESET: {
+		struct send_context *sc;
+		struct hfi1_devdata *dd;
+
+		if (!uctxt || !uctxt->dd || !uctxt->sc)
+			return -EINVAL;
+
+		/*
+		 * There is no protection here. User level has to
+		 * guarantee that no one will be writing to the send
+		 * context while it is being re-initialized.
+		 * If user level breaks that guarantee, it will break
+		 * it's own context and no one else's.
+		 */
+		dd = uctxt->dd;
+		sc = uctxt->sc;
+		/*
+		 * Wait until the interrupt handler has marked the
+		 * context as halted or frozen. Report error if we time
+		 * out.
+		 */
+		wait_event_interruptible_timeout(
+			sc->halt_wait, (sc->flags & SCF_HALTED),
+			msecs_to_jiffies(SEND_CTXT_HALT_TIMEOUT));
+		if (!(sc->flags & SCF_HALTED))
+			return -ENOLCK;
+
+		/*
+		 * If the send context was halted due to a Freeze,
+		 * wait until the device has been "unfrozen" before
+		 * resetting the context.
+		 */
+		if (sc->flags & SCF_FROZEN) {
+			wait_event_interruptible_timeout(
+				dd->event_queue,
+				!(ACCESS_ONCE(dd->flags) & HFI1_FROZEN),
+				msecs_to_jiffies(SEND_CTXT_HALT_TIMEOUT));
+			if (dd->flags & HFI1_FROZEN)
+				return -ENOLCK;
+
+			if (dd->flags & HFI1_FORCED_FREEZE)
+				/*
+				 * Don't allow context reset if we are into
+				 * forced freeze
+				 */
+				return -ENODEV;
+
+			sc_disable(sc);
+			ret = sc_enable(sc);
+			hfi1_rcvctrl(dd, HFI1_RCVCTRL_CTXT_ENB,
+				     uctxt->ctxt);
+		} else {
+			ret = sc_restart(sc);
+		}
+		if (!ret)
+			sc_return_credits(sc);
+		break;
+	}
+
+	case HFI1_IOCTL_GET_VERS:
+		uval = HFI1_USER_SWVERSION;
+		if (put_user(uval, (int __user *)arg))
+			return -EFAULT;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return ret;
+}
+
 static ssize_t hfi1_file_write(struct file *fp, const char __user *data,
 			       size_t count, loff_t *offset)
 {
diff --git a/include/uapi/rdma/hfi/hfi1_user.h b/include/uapi/rdma/hfi/hfi1_user.h
index aa48fbe..9fd8725 100644
--- a/include/uapi/rdma/hfi/hfi1_user.h
+++ b/include/uapi/rdma/hfi/hfi1_user.h
@@ -78,6 +78,11 @@ 
 #define HFI1_USER_SWMINOR 1
 
 /*
+ * We will encode the major/minor inside a single 32bit version number.
+ */
+#define HFI1_SWMAJOR_SHIFT 16
+
+/*
  * Set of HW and driver capability/feature bits.
  * These bit values are used to configure enabled/disabled HW and
  * driver features. The same set of bits are communicated to user
@@ -121,6 +126,41 @@ 
 #define HFI1_CMD_SET_PKEY        11     /* set context's pkey */
 #define HFI1_CMD_CTXT_RESET      12     /* reset context's HW send context */
 #define HFI1_CMD_TID_INVAL_READ  13     /* read TID cache invalidations */
+#define HFI1_CMD_GET_VERS	 14	/* get the version of the user cdev */
+
+/*
+ * User IOCTLs can not go above 128 if they do then see common.h and change the
+ * base for the snoop ioctl
+ */
+#define IB_IOCTL_MAGIC 0x1b /* See Documentation/ioctl/ioctl-number.txt */
+
+struct hfi1_cmd;
+#define HFI1_IOCTL_ASSIGN_CTXT \
+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_ASSIGN_CTXT, struct hfi1_user_info)
+#define HFI1_IOCTL_CTXT_INFO \
+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_INFO, struct hfi1_ctxt_info)
+#define HFI1_IOCTL_USER_INFO \
+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_USER_INFO, struct hfi1_base_info)
+#define HFI1_IOCTL_TID_UPDATE \
+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_UPDATE, struct hfi1_tid_info)
+#define HFI1_IOCTL_TID_FREE \
+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_FREE, struct hfi1_tid_info)
+#define HFI1_IOCTL_CREDIT_UPD \
+	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CREDIT_UPD)
+#define HFI1_IOCTL_RECV_CTRL \
+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_RECV_CTRL, int)
+#define HFI1_IOCTL_POLL_TYPE \
+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_POLL_TYPE, int)
+#define HFI1_IOCTL_ACK_EVENT \
+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_ACK_EVENT, unsigned long)
+#define HFI1_IOCTL_SET_PKEY \
+	_IOW(IB_IOCTL_MAGIC, HFI1_CMD_SET_PKEY, __u16)
+#define HFI1_IOCTL_CTXT_RESET \
+	_IO(IB_IOCTL_MAGIC, HFI1_CMD_CTXT_RESET)
+#define HFI1_IOCTL_TID_INVAL_READ \
+	_IOWR(IB_IOCTL_MAGIC, HFI1_CMD_TID_INVAL_READ, struct hfi1_tid_info)
+#define HFI1_IOCTL_GET_VERS \
+	_IOR(IB_IOCTL_MAGIC, HFI1_CMD_GET_VERS, int)
 
 #define _HFI1_EVENT_FROZEN_BIT         0
 #define _HFI1_EVENT_LINKDOWN_BIT       1