lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240717163437.GG1482543@nvidia.com>
Date: Wed, 17 Jul 2024 13:34:37 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Konstantin Taranov <kotaranov@...rosoft.com>,
	Konstantin Taranov <kotaranov@...ux.microsoft.com>,
	Wei Hu <weh@...rosoft.com>,
	"sharmaajay@...rosoft.com" <sharmaajay@...rosoft.com>,
	Long Li <longli@...rosoft.com>,
	"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

On Wed, Jul 17, 2024 at 09:22:50AM +0300, Leon Romanovsky wrote:
> On Tue, Jul 16, 2024 at 05:25:22PM +0000, Konstantin Taranov wrote:
> > > 
> > > 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.
> 
> Let's ask Jason, why is that? Do we allow to ignore max_inline_data?
> 
> librdmacm/examples/rdma_client.c
>   63         memset(&attr, 0, sizeof attr);
>   64         attr.cap.max_send_wr = attr.cap.max_recv_wr = 1;
>   65         attr.cap.max_send_sge = attr.cap.max_recv_sge = 1;
>   66         attr.cap.max_inline_data = 16;
>   67         attr.qp_context = id;
>   68         attr.sq_sig_all = 1;
>   69         ret = rdma_create_ep(&id, res, NULL, &attr);
>   70         // Check to see if we got inline data allowed or not
>   71         if (attr.cap.max_inline_data >= 16)
>   72                 send_flags = IBV_SEND_INLINE;
>   73         else
>   74                 printf("rdma_client: device doesn't support IBV_SEND_INLINE, "
>   75                        "using sge sends\n");

I think the idea expressed in this code is that if max_inline_data
requested too much it would be limited to the device capability.

ie qp creation should limit the requests values to what the HW can do,
similar to how entries and other work.

If the HW has no support it should return - for max_inline_data not an
error, I guess?

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ