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

[Jacob Moroni]

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"?

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