[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DU8PR83MB0975AC89F5149C284751B0A4B48EA@DU8PR83MB0975.EURPRD83.prod.outlook.com>
Date: Tue, 13 Jan 2026 12:27:57 +0000
From: Konstantin Taranov <kotaranov@...rosoft.com>
To: Leon Romanovsky <leon@...nel.org>, Konstantin Taranov
<kotaranov@...ux.microsoft.com>
CC: Shiraz Saleem <shirazsaleem@...rosoft.com>, Long Li
<longli@...rosoft.com>, "jgg@...pe.ca" <jgg@...pe.ca>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [EXTERNAL] Re: [PATCH rdma-next 1/1] RDMA/mana_ib: take CQ type
from the device type
> >
> > - is_rnic_cq = !!(ucmd.flags & MANA_IB_CREATE_RNIC_CQ);
>
> You need to add code which prohibits future use of this BIT(0) in ucmd.flags
> for backward compatibility and maybe delete MANA_IB_CREATE_RNIC_CQ
> from UAPI too.
>
> Thanks
>
Hi Leon. I thought that my proposed change is backward and forward compatible.
If I add code that prohibits this flag, then the older rdma-core will fail to create CQ,
as it sets this flag. Add rdma-core should set the flag to support older kernels.
So, the current solution is as follows:
rdma-core always sends the flag. The kernels without this patch still use this flag.
Newer kernels just ignore the flag and create the CQ according to the client.
It is not fully possible to retire this flag now, as we want to be backwards compatible and
support older kernels and older rdma-core.
Or did you mean something else? Or do I miss something?
Thanks
Powered by blists - more mailing lists