Subject: Re: [PATCH rdma-next] RDMA: Support more than 255 rdma ports

On Mon, Mar 01, 2021 at 09:04:20AM +0200, Leon Romanovsky wrote:

quoted

From: Mark Bloch <mbloch@nvidia.com>

Current code uses many different types when dealing with a port of a
RDMA device: u8, unsigned int and u32. Switch to u32 to clean up the
logic.

This allows us to make (at least) the core view consistent and use the
same type. Unfortunately not all places can be converted. Many uverbs
functions expect port to be u8 so keep those places in order not to break

UAPIs.

quoted

HW/Spec defined values must also not be changed.

With the switch to u32 we now can support devices with more than 255
ports. U32_MAX is reserved to make control logic a bit easier to deal
with. As a device with U32_MAX ports probably isn't going to happen
any time soon this seems like a non issue.

When a device with more than 255 ports is created uverbs will report
the RDMA device as having 255 ports as this is the max currently supported.

The verbs interface is not changed yet because the IBTA spec limits
the port size in too many places to be u8 and all applications that
relies in verbs won't be able to cope with this change. At this stage,
we are extending the interfaces that are using vendor channel solely

Once the limitation is lifted mlx5 in switchdev mode will be able to
have thousands of SFs created by the device. As the only instance of
an RDMA device that reports more than 255 ports will be a representor
device and it exposes itself as a RAW Ethernet only device
CM/MAD/IPoIB and other ULPs aren't effected by this change and their
sysfs/interfaces that are exposes to userspace can remain unchanged.

While here cleanup some alignment issues and remove unneeded sanity
checks (mainly in rdmavt),

Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---

Applied to for-next, I suppose this means the irdma driver needs re-spinning
already.

Sure.