[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PAXPR83MB0559D97004241D37765A151DB4A22@PAXPR83MB0559.EURPRD83.prod.outlook.com>
Date: Tue, 16 Jul 2024 17:25:22 +0000
From: Konstantin Taranov <kotaranov@...rosoft.com>
To: Leon Romanovsky <leon@...nel.org>
CC: Konstantin Taranov <kotaranov@...ux.microsoft.com>, Wei Hu
<weh@...rosoft.com>, "sharmaajay@...rosoft.com" <sharmaajay@...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: indicate that
inline data is not supported
>
> Yes, you are. If user asked for specific functionality (max_inline_data != 0) and
> your device doesn't support it, you should return an error.
>
> pvrdma, mlx4 and rvt are not good examples, they should return an error as
> well, but because of being legacy code, we won't change them.
>
> Thanks
>
I see. So I guess we can return a larger value, but not smaller. Right?
I will send v2 that fails QP creation then.
In this case, may I submit a patch to rdma-core that queries device caps before
trying to create a qp in rdma_client.c and rdma_server.c? As that code violates
what you described.
Thanks
Powered by blists - more mailing lists