Re: [PATCH net-next v4 5/5] selftests: drv-net: devmem: TX from a hugepage-backed dmabuf

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new TX large-niov test (check_tx_large_niov in devmem.py
  and check_nk_tx_large_niov in nk_devmem.py, both calling…

--

selftests: drv-net: devmem: TX from a hugepage-backed dmabuf

This adds a -H option to ncdevmem that backs the udmabuf with 2MB
hugepages. It also adds a TX test, run from both devmem.py and
nk_devmem.py, that sends a 3MB patterned buffer from that udmabuf so the
frags cross the 2MB net_iov boundary. The received data is checked by
comparing sha256 hashes from the remote side.

> diff --git a/tools/testing/selftests/drivers/net/hw/devmem_lib.py b/tools/testing/selftests/drivers/net/hw/devmem_lib.py
> index 71b916c161969..8058fd1ddd501 100644
> --- a/tools/testing/selftests/drivers/net/hw/devmem_lib.py
> +++ b/tools/testing/selftests/drivers/net/hw/devmem_lib.py

[ ... ]

> @@ -63,10 +66,15 @@ def require_devmem(cfg, rx_page_size=RX_PAGE_SIZE_DEFAULT):
>          # ncdevmem's queue range and cause the probe to fail.
>          cfg.devmem_supported = {size: _probe_devmem(cfg, size)
>                                  for size in PROBE_RX_PAGE_SIZES}
> +        cfg.devmem_hugepages = _probe_devmem(cfg, RX_PAGE_SIZE_DEFAULT,
> +                                             hugepages=True)
>  
>      if not cfg.devmem_supported[RX_PAGE_SIZE_DEFAULT]:
>          raise KsftSkipEx("Test requires devmem support")
>  
> +    if hugepages and not cfg.devmem_hugepages:
> +        raise KsftSkipEx("Test requires a 2MB hugepage-backed dmabuf")
> +

[Severity: Medium]
Can this probe succeed anywhere other than a 4K page kernel whose default
hugepage size is 2MB?

Before the probe, the only reservation is _reserve_hugepages(). It writes
64 to the default hstate's sysctl:

NR_HUGEPAGES_FILE = "/proc/sys/vm/nr_hugepages"

def _reserve_hugepages(want=64):

That sysctl only grows the pool for the default hugepage size. On arm64
with 16K or 64K base pages, the default size is 32MB or 512MB. An x86
kernel booted with default_hugepagesz=1G has the same problem. In those
setups the 2MB pool never grows.

With -H, udmabuf_alloc() always requests MFD_HUGETLB | MFD_HUGE_2MB. The
probe allocates its buffer in run_devmem_tests():

	mem = provider->alloc(getpagesize() * NUM_PAGES);

NUM_PAGES is 16000 and the size is rounded up to 2MB. That needs 32
hugepages on 4K pages, 125 on 16K pages and 500 on 64K pages. So even
when 2MB is the default size, 64 pages are too few on non-4K kernels.

In both cases UDMABUF_CREATE fails and cfg.devmem_hugepages ends up False.
check_tx_large_niov() and check_nk_tx_large_niov() then always skip with
"Test requires a 2MB hugepage-backed dmabuf". That message does not say
that the hugepage pool is the cause.

Before this patch, hugetlb was only used when rx_page_size >
getpagesize(). So -H looks like the first user to hit this on non-4K
kernels.

Would it make sense to reserve pages through
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages instead? The count
could be derived from the size ncdevmem will allocate, or -H could use a
smaller buffer.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261111224740.2744522-1-sdf%40fomichev.me