-----"Jason Gunthorpe" <jgg@xxxxxxxx> wrote: ----- >To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx> >From: "Jason Gunthorpe" <jgg@xxxxxxxx> >Date: 05/08/2019 03:08PM >Cc: "Leon Romanovsky" <leon@xxxxxxxxxx>, linux-rdma@xxxxxxxxxxxxxxx >Subject: Re: [PATCH v8 02/12] SIW main include file > >On Wed, May 08, 2019 at 08:07:59AM +0000, Bernard Metzler wrote: >> >> >> Memory access keys and QP IDs are generated as random >> >> >> numbers, since both are exposed to the application. >> >> >> Since XArray is not designed for sparsely distributed >> >> >> id ranges, I am still in favor of IDR for these two >> >> >> resources. >> > >> >IDR and xarray have identical underlying storage so this is >nonsense >> > >> >No new idr's or radix tree users will be accepted into rdma.... >Use >> >xarray >> > >> Sounds good to me! I just came across that introductory video from >Matthew, >> where he explicitly stated that xarray will be not very efficient >if the >> indices are not densely clustered. But maybe this is all far beyond >the >> 24bits of index space a memory key is in. So let me drop that IDR >thing >> completely, while handling randomized 24 bit memory keys. > >xarray/idr is a poor choice to store highly unclustered random data > >I'm not sure why this is a problem, shouldn't the driver be in >control >of mkey assignment? Just use xa_alloc_cyclic and it will be >sufficiently clustered to be efficient. > It is a recommendation to choose a hard to predict memory key (to make it hard for an attacker to guess it). From RFC 5040, sec 8.1.1: An RNIC MUST choose the value of STags in a way difficult to predict. It is RECOMMENDED to sparsely populate them over the full available range. Since I did not want to roll my own bug-prone key based lookup, I chose idr. If you tell me xarray is just as inefficient as idr for sparse index distributions, I'll take xarray. Thanks, Bernard.
