| Message ID | 20200318124329.52111-1-leon@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce dynamic UAR allocation mode | expand |
On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > From: Leon Romanovsky <leonro@mellanox.com> > > From Yishai, > > This series exposes API to enable a dynamic allocation and management of a > UAR which now becomes to be a regular uobject. > > Moving to that mode enables allocating a UAR only upon demand and drop the > redundant static allocation of UARs upon context creation. > > In addition, it allows master and secondary processes that own the same command > FD to allocate and manage UARs according to their needs, this can’t be achieved > today. > > As part of this option, QP & CQ creation flows were adapted to support this > dynamic UAR mode once asked by user space. > > Once this mode is asked by mlx5 user space driver on a given context, it will > be mutual exclusive, means both the static and legacy dynamic modes for using > UARs will be blocked. > > The legacy modes are supported for backward compatible reasons, looking > forward we expect this new mode to be the default. We are starting to accumulate a lot of code that is now old-rdma-core only. I have been wondering if we should add something like #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 #endif So we can keep track of what is actually a used code flow and what is now hard to test legacy code. eg this config would also disable the write interface(), turn off compat write interfaces as they are switched to use ioctl, etc, etc. Jason
On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro@mellanox.com> > > > > From Yishai, > > > > This series exposes API to enable a dynamic allocation and management of a > > UAR which now becomes to be a regular uobject. > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > redundant static allocation of UARs upon context creation. > > > > In addition, it allows master and secondary processes that own the same command > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > today. > > > > As part of this option, QP & CQ creation flows were adapted to support this > > dynamic UAR mode once asked by user space. > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > be mutual exclusive, means both the static and legacy dynamic modes for using > > UARs will be blocked. > > > > The legacy modes are supported for backward compatible reasons, looking > > forward we expect this new mode to be the default. > > We are starting to accumulate a lot of code that is now old-rdma-core > only. Agree > > I have been wondering if we should add something like > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > #endif From one side it will definitely help to see old code, but from another it will create many ifdef inside of the code with a very little chance of testing. Also we will continue to have the same problem to decide when we can delete this code. > > So we can keep track of what is actually a used code flow and what is > now hard to test legacy code. > > eg this config would also disable the write interface(), turn off > compat write interfaces as they are switched to use ioctl, etc, etc. What about if we introduce one ifdef, let's say CONFIG_INFINIBAND_LEGACY and put everything that will be declared as legacy to that bucket? And once every 5 (???) years delete everything from that bucket. > > Jason
On Wed, Mar 18, 2020 at 03:14:50PM +0200, Leon Romanovsky wrote: > On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > > From: Leon Romanovsky <leonro@mellanox.com> > > > > > > From Yishai, > > > > > > This series exposes API to enable a dynamic allocation and management of a > > > UAR which now becomes to be a regular uobject. > > > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > > redundant static allocation of UARs upon context creation. > > > > > > In addition, it allows master and secondary processes that own the same command > > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > > today. > > > > > > As part of this option, QP & CQ creation flows were adapted to support this > > > dynamic UAR mode once asked by user space. > > > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > > be mutual exclusive, means both the static and legacy dynamic modes for using > > > UARs will be blocked. > > > > > > The legacy modes are supported for backward compatible reasons, looking > > > forward we expect this new mode to be the default. > > > > We are starting to accumulate a lot of code that is now old-rdma-core > > only. > > Agree > > > > > I have been wondering if we should add something like > > > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > > #endif > > From one side it will definitely help to see old code, but from another > it will create many ifdef inside of the code with a very little chance > of testing. Also we will continue to have the same problem to decide when > we can delete this code. Well, it doesn't have to be an #ifdef, eg just sticking if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) return -ENOPROTOOPT; at the top of obsolete functions would go a long way > > So we can keep track of what is actually a used code flow and what is > > now hard to test legacy code. > > > > eg this config would also disable the write interface(), turn off > > compat write interfaces as they are switched to use ioctl, etc, etc. > > What about if we introduce one ifdef, let's say CONFIG_INFINIBAND_LEGACY > and put everything that will be declared as legacy to that bucket? And > once every 5 (???) years delete everything from that bucket. It is much harder to see what is really old vs only a little old I'm not sure we can ever completely delete any of this, but at least the distros can make an informed choice to either do more detailed test of old libraries or disable those code paths. Jason
On Wed, Mar 18, 2020 at 10:21:00AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 18, 2020 at 03:14:50PM +0200, Leon Romanovsky wrote: > > On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > > > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > > > From: Leon Romanovsky <leonro@mellanox.com> > > > > > > > > From Yishai, > > > > > > > > This series exposes API to enable a dynamic allocation and management of a > > > > UAR which now becomes to be a regular uobject. > > > > > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > > > redundant static allocation of UARs upon context creation. > > > > > > > > In addition, it allows master and secondary processes that own the same command > > > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > > > today. > > > > > > > > As part of this option, QP & CQ creation flows were adapted to support this > > > > dynamic UAR mode once asked by user space. > > > > > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > > > be mutual exclusive, means both the static and legacy dynamic modes for using > > > > UARs will be blocked. > > > > > > > > The legacy modes are supported for backward compatible reasons, looking > > > > forward we expect this new mode to be the default. > > > > > > We are starting to accumulate a lot of code that is now old-rdma-core > > > only. > > > > Agree > > > > > > > > I have been wondering if we should add something like > > > > > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > > > #endif > > > > From one side it will definitely help to see old code, but from another > > it will create many ifdef inside of the code with a very little chance > > of testing. Also we will continue to have the same problem to decide when > > we can delete this code. > > Well, it doesn't have to be an #ifdef, eg just sticking > > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > return -ENOPROTOOPT; > > at the top of obsolete functions would go a long way First, how will you set this min_version? hordcoded in the kernel code? Second, it will work for simple flows, but can be extremely complex if your code looks like: if (old_version) do something if (new version) do something else You will need to add logic to handle this -ENOPROTOOPT error value. > > > > So we can keep track of what is actually a used code flow and what is > > > now hard to test legacy code. > > > > > > eg this config would also disable the write interface(), turn off > > > compat write interfaces as they are switched to use ioctl, etc, etc. > > > > What about if we introduce one ifdef, let's say CONFIG_INFINIBAND_LEGACY > > and put everything that will be declared as legacy to that bucket? And > > once every 5 (???) years delete everything from that bucket. > > It is much harder to see what is really old vs only a little old > > I'm not sure we can ever completely delete any of this, but at least > the distros can make an informed choice to either do more detailed > test of old libraries or disable those code paths. It will be nice to hear how distros decide to disable/drop the code. Thanks > > Jason
On Wed, Mar 18, 2020 at 03:56:31PM +0200, Leon Romanovsky wrote: > On Wed, Mar 18, 2020 at 10:21:00AM -0300, Jason Gunthorpe wrote: > > On Wed, Mar 18, 2020 at 03:14:50PM +0200, Leon Romanovsky wrote: > > > On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > > > > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > > > > From: Leon Romanovsky <leonro@mellanox.com> > > > > > > > > > > From Yishai, > > > > > > > > > > This series exposes API to enable a dynamic allocation and management of a > > > > > UAR which now becomes to be a regular uobject. > > > > > > > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > > > > redundant static allocation of UARs upon context creation. > > > > > > > > > > In addition, it allows master and secondary processes that own the same command > > > > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > > > > today. > > > > > > > > > > As part of this option, QP & CQ creation flows were adapted to support this > > > > > dynamic UAR mode once asked by user space. > > > > > > > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > > > > be mutual exclusive, means both the static and legacy dynamic modes for using > > > > > UARs will be blocked. > > > > > > > > > > The legacy modes are supported for backward compatible reasons, looking > > > > > forward we expect this new mode to be the default. > > > > > > > > We are starting to accumulate a lot of code that is now old-rdma-core > > > > only. > > > > > > Agree > > > > > > > > > > > I have been wondering if we should add something like > > > > > > > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > > > > #endif > > > > > > From one side it will definitely help to see old code, but from another > > > it will create many ifdef inside of the code with a very little chance > > > of testing. Also we will continue to have the same problem to decide when > > > we can delete this code. > > > > Well, it doesn't have to be an #ifdef, eg just sticking > > > > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > > return -ENOPROTOOPT; > > > > at the top of obsolete functions would go a long way > > First, how will you set this min_version? hordcoded in the kernel > code? Yes, when a rdma-core release obsoletes the code path then it can become annotated. > Second, it will work for simple flows, but can be extremely complex > if your code looks like: > if (old_version) > do something > if (new version) > do something else Well, we'd avoid making such complications, it would be something like if (flag & foo) { if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) return -ENOPROTOOPT; [keep going as before] } At least we now know this conditional path isn't used / isn't covered by testing Doug? What does a distro think? Jason
On Wed, Mar 18, 2020 at 11:00:01AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 18, 2020 at 03:56:31PM +0200, Leon Romanovsky wrote: > > On Wed, Mar 18, 2020 at 10:21:00AM -0300, Jason Gunthorpe wrote: > > > On Wed, Mar 18, 2020 at 03:14:50PM +0200, Leon Romanovsky wrote: > > > > On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > > > > > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > > > > > From: Leon Romanovsky <leonro@mellanox.com> > > > > > > > > > > > > From Yishai, > > > > > > > > > > > > This series exposes API to enable a dynamic allocation and management of a > > > > > > UAR which now becomes to be a regular uobject. > > > > > > > > > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > > > > > redundant static allocation of UARs upon context creation. > > > > > > > > > > > > In addition, it allows master and secondary processes that own the same command > > > > > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > > > > > today. > > > > > > > > > > > > As part of this option, QP & CQ creation flows were adapted to support this > > > > > > dynamic UAR mode once asked by user space. > > > > > > > > > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > > > > > be mutual exclusive, means both the static and legacy dynamic modes for using > > > > > > UARs will be blocked. > > > > > > > > > > > > The legacy modes are supported for backward compatible reasons, looking > > > > > > forward we expect this new mode to be the default. > > > > > > > > > > We are starting to accumulate a lot of code that is now old-rdma-core > > > > > only. > > > > > > > > Agree > > > > > > > > > > > > > > I have been wondering if we should add something like > > > > > > > > > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > > > > > #endif > > > > > > > > From one side it will definitely help to see old code, but from another > > > > it will create many ifdef inside of the code with a very little chance > > > > of testing. Also we will continue to have the same problem to decide when > > > > we can delete this code. > > > > > > Well, it doesn't have to be an #ifdef, eg just sticking > > > > > > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > > > return -ENOPROTOOPT; > > > > > > at the top of obsolete functions would go a long way > > > > First, how will you set this min_version? hordcoded in the kernel > > code? > > Yes, when a rdma-core release obsoletes the code path then it can > become annotated. > > > Second, it will work for simple flows, but can be extremely complex > > if your code looks like: > > if (old_version) > > do something > > if (new version) > > do something else > > Well, we'd avoid making such complications, it would be something like > > if (flag & foo) { > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > return -ENOPROTOOPT; > [keep going as before] > } > > At least we now know this conditional path isn't used / isn't covered > by testing I'm ok with this approach because it helps us to find those dead paths, but have last question, shouldn't this be achieved with proper documentation of every flag instead of adding CONFIG_..? > > Doug? What does a distro think? > > Jason
On Wed, Mar 18, 2020 at 04:09:32PM +0200, Leon Romanovsky wrote: > On Wed, Mar 18, 2020 at 11:00:01AM -0300, Jason Gunthorpe wrote: > > On Wed, Mar 18, 2020 at 03:56:31PM +0200, Leon Romanovsky wrote: > > > On Wed, Mar 18, 2020 at 10:21:00AM -0300, Jason Gunthorpe wrote: > > > > On Wed, Mar 18, 2020 at 03:14:50PM +0200, Leon Romanovsky wrote: > > > > > On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > > > > > > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > > > > > > From: Leon Romanovsky <leonro@mellanox.com> > > > > > > > > > > > > > > From Yishai, > > > > > > > > > > > > > > This series exposes API to enable a dynamic allocation and management of a > > > > > > > UAR which now becomes to be a regular uobject. > > > > > > > > > > > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > > > > > > redundant static allocation of UARs upon context creation. > > > > > > > > > > > > > > In addition, it allows master and secondary processes that own the same command > > > > > > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > > > > > > today. > > > > > > > > > > > > > > As part of this option, QP & CQ creation flows were adapted to support this > > > > > > > dynamic UAR mode once asked by user space. > > > > > > > > > > > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > > > > > > be mutual exclusive, means both the static and legacy dynamic modes for using > > > > > > > UARs will be blocked. > > > > > > > > > > > > > > The legacy modes are supported for backward compatible reasons, looking > > > > > > > forward we expect this new mode to be the default. > > > > > > > > > > > > We are starting to accumulate a lot of code that is now old-rdma-core > > > > > > only. > > > > > > > > > > Agree > > > > > > > > > > > > > > > > > I have been wondering if we should add something like > > > > > > > > > > > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > > > > > > #endif > > > > > > > > > > From one side it will definitely help to see old code, but from another > > > > > it will create many ifdef inside of the code with a very little chance > > > > > of testing. Also we will continue to have the same problem to decide when > > > > > we can delete this code. > > > > > > > > Well, it doesn't have to be an #ifdef, eg just sticking > > > > > > > > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > > > > return -ENOPROTOOPT; > > > > > > > > at the top of obsolete functions would go a long way > > > > > > First, how will you set this min_version? hordcoded in the kernel > > > code? > > > > Yes, when a rdma-core release obsoletes the code path then it can > > become annotated. > > > > > Second, it will work for simple flows, but can be extremely complex > > > if your code looks like: > > > if (old_version) > > > do something > > > if (new version) > > > do something else > > > > Well, we'd avoid making such complications, it would be something like > > > > if (flag & foo) { > > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > > return -ENOPROTOOPT; > > [keep going as before] > > } > > > > At least we now know this conditional path isn't used / isn't covered > > by testing > > I'm ok with this approach because it helps us to find those dead > paths, but have last question, shouldn't this be achieved with > proper documentation of every flag instead of adding CONFIG_..? How do you mean? The other half of this idea is to disable obsolete un tested code to avoid potential bugs. Which requires CONFIG_? Jason
On Wed, Mar 18, 2020 at 11:12:08AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 18, 2020 at 04:09:32PM +0200, Leon Romanovsky wrote: > > On Wed, Mar 18, 2020 at 11:00:01AM -0300, Jason Gunthorpe wrote: > > > On Wed, Mar 18, 2020 at 03:56:31PM +0200, Leon Romanovsky wrote: > > > > On Wed, Mar 18, 2020 at 10:21:00AM -0300, Jason Gunthorpe wrote: > > > > > On Wed, Mar 18, 2020 at 03:14:50PM +0200, Leon Romanovsky wrote: > > > > > > On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > > > > > > > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > > > > > > > From: Leon Romanovsky <leonro@mellanox.com> > > > > > > > > > > > > > > > > From Yishai, > > > > > > > > > > > > > > > > This series exposes API to enable a dynamic allocation and management of a > > > > > > > > UAR which now becomes to be a regular uobject. > > > > > > > > > > > > > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > > > > > > > redundant static allocation of UARs upon context creation. > > > > > > > > > > > > > > > > In addition, it allows master and secondary processes that own the same command > > > > > > > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > > > > > > > today. > > > > > > > > > > > > > > > > As part of this option, QP & CQ creation flows were adapted to support this > > > > > > > > dynamic UAR mode once asked by user space. > > > > > > > > > > > > > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > > > > > > > be mutual exclusive, means both the static and legacy dynamic modes for using > > > > > > > > UARs will be blocked. > > > > > > > > > > > > > > > > The legacy modes are supported for backward compatible reasons, looking > > > > > > > > forward we expect this new mode to be the default. > > > > > > > > > > > > > > We are starting to accumulate a lot of code that is now old-rdma-core > > > > > > > only. > > > > > > > > > > > > Agree > > > > > > > > > > > > > > > > > > > > I have been wondering if we should add something like > > > > > > > > > > > > > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > > > > > > > #endif > > > > > > > > > > > > From one side it will definitely help to see old code, but from another > > > > > > it will create many ifdef inside of the code with a very little chance > > > > > > of testing. Also we will continue to have the same problem to decide when > > > > > > we can delete this code. > > > > > > > > > > Well, it doesn't have to be an #ifdef, eg just sticking > > > > > > > > > > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > > > > > return -ENOPROTOOPT; > > > > > > > > > > at the top of obsolete functions would go a long way > > > > > > > > First, how will you set this min_version? hordcoded in the kernel > > > > code? > > > > > > Yes, when a rdma-core release obsoletes the code path then it can > > > become annotated. > > > > > > > Second, it will work for simple flows, but can be extremely complex > > > > if your code looks like: > > > > if (old_version) > > > > do something > > > > if (new version) > > > > do something else > > > > > > Well, we'd avoid making such complications, it would be something like > > > > > > if (flag & foo) { > > > if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 21) > > > return -ENOPROTOOPT; > > > [keep going as before] > > > } > > > > > > At least we now know this conditional path isn't used / isn't covered > > > by testing > > > > I'm ok with this approach because it helps us to find those dead > > paths, but have last question, shouldn't this be achieved with > > proper documentation of every flag instead of adding CONFIG_..? > > How do you mean? > > The other half of this idea is to disable obsolete un tested code to > avoid potential bugs. Which requires CONFIG_? The second part is achievable by distros when they will decide to support starting from version X. The same decision is not so easy to do in the upstream. Let's take as an example this feature. It will be set as default from rdma-core v29 and the legacy code will be guarded by "if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 29)". When will change CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION to be above 29? So we will delete such legacy code. In the world where we are not breaking user space, it will never happen. It means that upstream doesn't get anything from those CONFIG_*s. Thanks > > Jason
On Wed, Mar 18, 2020 at 04:24:55PM +0200, Leon Romanovsky wrote: > > > I'm ok with this approach because it helps us to find those dead > > > paths, but have last question, shouldn't this be achieved with > > > proper documentation of every flag instead of adding CONFIG_..? > > > > How do you mean? > > > > The other half of this idea is to disable obsolete un tested code to > > avoid potential bugs. Which requires CONFIG_? > > The second part is achievable by distros when they will decide to > support starting from version X. The same decision is not so easy > to do in the upstream. Upstream will probably carry the code for a long, long time, that doesn't mean the distros don't get value by using a shorter time window > Let's take as an example this feature. It will be set as default from > rdma-core v29 and the legacy code will be guarded by > "if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 29)". When will change > CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION to be above 29? So we will > delete such legacy code. First the distros will decide in their own kconfigs where they want to set the value. Then the upstream kernel will decide some default value Then maybe we could talk about lowest values when enough of the user community uses a higher value Jason
On Wed, Mar 18, 2020 at 11:39:03AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 18, 2020 at 04:24:55PM +0200, Leon Romanovsky wrote: > > > > I'm ok with this approach because it helps us to find those dead > > > > paths, but have last question, shouldn't this be achieved with > > > > proper documentation of every flag instead of adding CONFIG_..? > > > > > > How do you mean? > > > > > > The other half of this idea is to disable obsolete un tested code to > > > avoid potential bugs. Which requires CONFIG_? > > > > The second part is achievable by distros when they will decide to > > support starting from version X. The same decision is not so easy > > to do in the upstream. > > Upstream will probably carry the code for a long, long time, that > doesn't mean the distros don't get value by using a shorter time > window Sure > > > Let's take as an example this feature. It will be set as default from > > rdma-core v29 and the legacy code will be guarded by > > "if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 29)". When will change > > CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION to be above 29? So we will > > delete such legacy code. > > First the distros will decide in their own kconfigs where they want to > set the value. > > Then the upstream kernel will decide some default value > > Then maybe we could talk about lowest values when enough of the user > community uses a higher value I think that you over-optimistic here, but let's hear other voices here. Thanks > > Jason
From: Leon Romanovsky <leonro@mellanox.com> From Yishai, This series exposes API to enable a dynamic allocation and management of a UAR which now becomes to be a regular uobject. Moving to that mode enables allocating a UAR only upon demand and drop the redundant static allocation of UARs upon context creation. In addition, it allows master and secondary processes that own the same command FD to allocate and manage UARs according to their needs, this can’t be achieved today. As part of this option, QP & CQ creation flows were adapted to support this dynamic UAR mode once asked by user space. Once this mode is asked by mlx5 user space driver on a given context, it will be mutual exclusive, means both the static and legacy dynamic modes for using UARs will be blocked. The legacy modes are supported for backward compatible reasons, looking forward we expect this new mode to be the default. Thanks Yishai Hadas (4): IB/mlx5: Expose UAR object and its alloc/destroy commands IB/mlx5: Extend CQ creation to get uar page index from user space IB/mlx5: Extend QP creation to get uar page index from user space IB/mlx5: Move to fully dynamic UAR mode once user space supports it drivers/infiniband/hw/mlx5/cq.c | 21 ++- drivers/infiniband/hw/mlx5/main.c | 185 ++++++++++++++++++++-- drivers/infiniband/hw/mlx5/mlx5_ib.h | 2 + drivers/infiniband/hw/mlx5/qp.c | 33 ++-- include/linux/mlx5/driver.h | 1 + include/rdma/uverbs_ioctl.h | 2 +- include/uapi/rdma/mlx5-abi.h | 6 + include/uapi/rdma/mlx5_user_ioctl_cmds.h | 18 +++ include/uapi/rdma/mlx5_user_ioctl_verbs.h | 5 + 9 files changed, 246 insertions(+), 27 deletions(-) -- 2.24.1