RE: [EXTERNAL] Re: [PATCH rdma-next v3 1/1] RDMA/mana_ib: memory windows

[Konstantin Taranov]

> On Tue, Mar 31, 2026 at 02:08:51AM -0700, Konstantin Taranov wrote:
> > From: Konstantin Taranov <kotaranov@xxxxxxxxxxxxx>
> >
> > Implement .alloc_mw() and .dealloc_mw() for mana device.
> >
> > Signed-off-by: Konstantin Taranov <kotaranov@xxxxxxxxxxxxx>
> > Reviewed-by: Long Li <longli@xxxxxxxxxxxxx>
> > ---
> > v3: Use v2 request
> > v2: fixed comments. Cleaned up the use of mana_gd_send_request()
> > drivers/infiniband/hw/mana/device.c  |  3 ++
> > drivers/infiniband/hw/mana/mana_ib.h |  8 +++++
> >  drivers/infiniband/hw/mana/mr.c      | 54
> +++++++++++++++++++++++++++-
> >  include/net/mana/gdma.h              |  5 +++
> >  4 files changed, 69 insertions(+), 1 deletion(-)
> 
> How did you test this patch? How can applications know that alloc_mw is
> supported now if you didn't set IB_DEVICE_MEM_WINDOW and props-
> >max_mw?

Our mana HW supports MWs and I tested against it. That V1 and V2 helps the HW correctly
detect request struct size and for MWs it does not matter as its fields fit into v1 size.
The application can just try to create an MW and see if it works.
prop->max_mw will be the same as max_mr, since they are modelled similarly in the HW.
IB_DEVICE_MEM_WINDOW is an informative and not enforced, so nothing prevents to test it.

My plan was to upstream MWs, UC, RC support of MW, and then upstream a patch that
correctly indicates that it is all available. As now even if we report MW caps, there is no QPs that
can take advantage of it. In MANA, WQEs that perform memory operations should be submitted to
special queue, which is different from the send queue. So UC patch includes the special queue,
and an RC patch will expose an extra queue.

If you say, I must add that caps now, I can send v4 with the max_mw and IB_DEVICE_MEM_WINDOW.

Thanks

> 
> Thanks