On Fri, Jun 14, 2019 at 01:28:47AM +0530, Kashyap Desai wrote:
quoted
Is there any changes in API blk_queue_virt_boundary? I could not find
relevant code which account for this. Can you help ?
Which git repo shall I use for testing ? That way I can confirm, I
didn't miss relevant changes.
Latest mainline plus the series (which is about to get resent).
blk_queue_virt_boundary now forced an unlimited max_hw_sectors as that
is
how PRP-like schemes work, to work around a block driver merging bug.
But
we also need to communicate that limit to the DMA layer so that we don't
set
a smaller iommu segment size limitation.
quoted
quoted
From your above explanation, it means (after this patch) max segment
size
of the MR controller will be set to 4K.
Earlier it is possible to receive single SGE of 64K datalength (Since
max seg size was 64K), but now the same buffer will reach the driver
having 16 SGEs (Each SGE will contain 4K length).
No, there is no more limit for the size of the segment at all, as for
PRPs each
PRP is sort of a segment from the hardware perspective.
We just require the segments to not have gaps, as PRPs don't allow for
that.
Thanks for clarification. I have also observed that max_segment_size Is
unchanged and it is 64K.
That being said I think these patches are wrong for the case of megaraid
or
mpt having both NVMe and SAS/ATA devices behind a single controller.
Is that a valid configuration?
Yes. This is a valid configuration.