External email: Use caution opening links or attachments
On Mon, 28 Nov 2022 16:56:39 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:
On Mon, Nov 28, 2022 at 01:36:30PM -0700, Alex Williamson wrote:
On Mon, 28 Nov 2022 15:40:23 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:
On Mon, Nov 28, 2022 at 11:50:03AM -0700, Alex Williamson wrote:
There's a claim here about added complexity that I'm not really seeing.
It looks like we simply make an ioctl call here and scale our buffer
based on the minimum of the returned device estimate or our upper
bound.
I'm not keen on this, for something like mlx5 that has a small precopy
size and large post-copy size it risks running with an under allocated
buffer, which is harmful to performance.
I'm trying to weed out whether there are device assumptions in the
implementation, seems like maybe we found one.
I don't think there are assumptions. Any correct kernel driver should
be able to do this transfer out of the FD byte-at-a-time.
This buffer size is just a random selection for now until we get
multi-fd and can sit down, benchmark and optimize this properly.
We can certainly still do that, but I'm still failing to see how
buffer_size = min(MIG_DATA_SIZE, 1MB) is such an imposition on the
complexity or over-eager optimization.