[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZDVoH0W27xo6mAbW@nvidia.com>
Date: Tue, 11 Apr 2023 11:01:03 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Leon Romanovsky <leonro@...dia.com>,
Avihai Horon <avihaih@...dia.com>, Aya Levin <ayal@...dia.com>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org,
linux-rdma@...r.kernel.org, Meir Lichtinger <meirl@...lanox.com>,
Michael Guralnik <michaelgur@...lanox.com>,
netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
Saeed Mahameed <saeedm@...dia.com>,
Shay Drory <shayd@...dia.com>
Subject: Re: [PATCH rdma-next 0/4] Allow relaxed ordering read in VFs and VMs
On Mon, Apr 10, 2023 at 04:07:49PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@...dia.com>
>
> From Avihai,
>
> Currently, Relaxed Ordering (RO) can't be used in VFs directly and in
> VFs assigned to QEMU, even if the PF supports RO. This is due to issues
> in reporting/emulation of PCI config space RO bit and due to current
> HCA capability behavior.
>
> This series fixes it by using a new HCA capability and by relying on FW
> to do the "right thing" according to the PF's PCI config space RO value.
>
> Allowing RO in VFs and VMs is valuable since it can greatly improve
> performance on some setups. For example, testing throughput of a VF on
> an AMD EPYC 7763 and ConnectX-6 Dx setup showed roughly 60% performance
> improvement.
>
> Thanks
>
> Avihai Horon (4):
> RDMA/mlx5: Remove pcie_relaxed_ordering_enabled() check for RO write
> RDMA/mlx5: Check pcie_relaxed_ordering_enabled() in UMR
> net/mlx5: Update relaxed ordering read HCA capabilities
> RDMA/mlx5: Allow relaxed ordering read in VFs and VMs
This looks OK, but the patch structure is pretty confusing.
It seems to me there are really only two patches here, the first is to
add some static inline
'mlx5 supports read ro'
which supports both the cap bits described in
the PRM, with a little comment to explain that old devices only set
the old cap.
And a second patch to call it in all the places we need to check before
setting the mkc ro read bit.
Maybe a final third patch to sort out that mistake in the write side.
But this really doesn't have anything to do with VFs and VMs, this is
adjusting the code to follow the current PRM because the old one was
mis-desgined.
Jason
Powered by blists - more mailing lists