Re: [PATCH rdma-next 1/1] RDMA/mana_ib: Adopt robust udata

[Konstantin Taranov]

> -----Original Message-----
> From: Jacob Moroni <jmoroni@xxxxxxxxxx>
> Sent: Thursday, 25 June 2026 15:29
> To: Konstantin Taranov <kotaranov@xxxxxxxxxxxxx>
> Cc: Konstantin Taranov <kotaranov@xxxxxxxxxxxxxxxxxxx>;
> shirazsaleem@xxxxxxxxxxxxx; Long Li <longli@xxxxxxxxxxxxx>;
> jgg@xxxxxxxx; leon@xxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: [EXTERNAL] Re: [PATCH rdma-next 1/1] RDMA/mana_ib: Adopt
> robust udata
> 
> Thanks for explaining. I think it makes sense.
> 
> > Otherwise, the change would be more complex: new response for
> > alloc_ucontex
> 
> Do you still need new response fields/bits for alloc_ucontext so that the
> client knows whether it can actually use the new capability - like a driver
> "ack"?

I do think that an ack per capability bit offers anything useful. Imagine if I did not have a
client cap bit, I could still grow responses as I want and I could send back to the client
that certain kernel feature is available. So, the new clients could use it without telling the kernel
its caps in the first place. So, the main use of the client caps is to add client-wide backward compatible features,
which allow to reduce boiler plate code later in the kernel. E.g., I do not plan to use that caps for features
that require kernel support. Soon I will resend the patch with short PDIDs. There is no benefit in telling the
kernel that rdma-core has a cap to request short PDIDs, as kernel must support it.

I know that drivers often ack the bits with the same flags, but I do not see what it enables.
Having separately defined client and kernel capabilities seems more universal to me.
So in upcoming patches I will do add kernel capabilities in the response (e.g., for short PDs).

-Konstantin

> 
> The fixed WQE capability may be special in that it sounds more like a one-
> way hint, but I am wondering about features that require explicit kernel
> support (just hypothetical) before the client can actually use it, like maybe
> features that require activation in HW, etc.
> 
> > With the wave of robust udata,
> > providers will be locked to one udata request format for alloc_ucontext()
> without a chance of extending.
> > That is why, I try to introduce the idea now.
> 
> Good point - I was wondering if alloc_ucontext would be an exception to the
> robust udata policy since it's the first part of the handshake. As in, clients
> would be allowed to provide non-zero udata input that the driver may not
> understand and it would be up to the driver to acknowledge features or not
> by sending a response. Seems kind of similar to how I think your solution
> would work.
> 
> Otherwise, it's kind of locked in as you said. Enforcing a real comp_mask in
> alloc_ucontext would mean that clients wouldn't be compatible with older
> kernels since context allocation is too early for them to know which bits are
> allowed or not. I could be misunderstanding though.
> 
> Thanks,
> Jake