Re: [PATCH v2] block: Increase BLK_DEF_MAX_SECTORS_CAP

[Keith Busch <kbusch@kernel.org>]

On Fri, Apr 03, 2026 at 08:25:04AM +0900, Damien Le Moal wrote:
> Thanks for this. But where do you see that the DMA pool size is 2M ?

It's not that the DMA pool size is 2M. NVMe PRP can describe 2M of data
with 4k worth of PRP entries.

I was thinking it's the "page_size", assuming it was 4k, but I misread
the argument order:

        ioc->pcie_sgl_dma_pool =
            dma_pool_create("PCIe SGL pool", &ioc->pdev->dev, sz,
            ioc->page_size, 0);

The dma element size is whatever "sz" is, and ioc->page_size is just the
alignment. It still doesn't seem like it's big enough, though.

The function _base_build_nvme_prp() takes a pointer to the pcie_sgl that
was allocated from that pool and writes the prp entries to it without
doing chaining PRP elements from the end of the list, so it looks like
it just overruns it if you have a large transfer.

> Looking at the code, it seems that ioc->pcie_sgl_dma_pool is created using
> _base_allocate_pcie_sgl_pool() with a size that is calculated as:
> 
>         /*
>          * The number of NVMe page sized blocks needed is:
>          *     (((sg_tablesize * 8) - 1) / (page_size - 8)) + 1
>          * ((sg_tablesize * 8) - 1) is the max PRP's minus the first PRP entry
>          * that is placed in the main message frame.  8 is the size of each PRP
>          * entry or PRP list pointer entry.  8 is subtracted from page_size
>          * because of the PRP list pointer entry at the end of a page, so this
>          * is not counted as a PRP entry.  The 1 added page is a round up.

This doesn't sound right because sg_tablesize refers to a scatterlist
that may contain multi-page entries, but nvme PRP's need a single entry
per page, so it's too low when you have contiguous memory.