# Re: \[PATCH rdma-next v1 1/6\] IB/uverbs: Allow CQ moderation with modify CQ

- From: Yishai Hadas \<hidden\>
- Date: 2017-10-31 11:31:28 
- List: linux-rdma
- Page: https://ratatoskr.run/linux-rdma/2017/10/15450220

```text
On 10/31/2017 7:08 AM, Leon Romanovsky wrote:
> On Mon, Oct 30, 2017 at 05:07:53PM -0600, Jason Gunthorpe wrote:
>> On Mon, Oct 30, 2017 at 09:09:52PM +0200, Leon Romanovsky wrote:
>>
>>> However, I don't think that kernel to libibverbs API should follow the
>>> same path. The centralized entry points to the kernel provides better
>>> enforcement and minimizes system call bloat.
>>
>> How so? I didn't think selinux intersected with the CQs at all..
>> I've never worried about the # of verbs entries, we have so many
>> already.
>
> Not SELinux enforcement, but various copy_{to|from}_user checks, unified
> return values, easy folding in case of errors, e.t.c.
>
> It is a matter of personal view and less technical thing. You prefer bazillion
> entry points to the kernel and I think that such design good for user-space only,
> and mostly not applicable for kernel<->user interfaces.

Even for the user area having a dedicated 'setter' per field might bring some redundant overhead and limitation. This will prevent the option from application to modify few fields in one API and resulted in a system call per field. Also libibverbs and user drivers may need to maintain some wrapping over the kernel command which in turn might lead to some extra/duplication of code. I would vote to follow modify QP/SRQ/WQ by having one API with an 'attr_mask' field as this series has introduced in both kernel and user.

The matching user space series was published and can be seen at:
https://github.com/linux-rdma/rdma-core/pull/238
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
```