Hello Jingjing, On Sun, 23 Aug 2026 at 16:07, Raghavendra Ningoji <[email protected]> wrote: > > This series adds support for the Non-Transparent Bridge (NTB) endpoints > integrated in AMD EPYC Embedded "Turin", "Genoa" and "Siena" processors > to the raw/ntb driver. > > The NTB rawdev framework was originally written around the Intel > back-to-back topology and the built-in scratchpad handshake protocol. > Patch 1 generalizes it with a few vendor-neutral hooks so other vendors > can reuse the common code; the Intel driver is unaffected since the new > hooks fall back to the built-in paths when NULL. Patch 2 adds the AMD > hardware driver, and patch 3 documents the new support. > > A few AMD-specific hardware details worth noting for reviewers: > > - Primary/secondary topology. One endpoint enumerates as the primary > (device ID 0x14c0) and the other as the secondary (0x14c3), rather > than the Intel back-to-back model. > > - Packed scratchpad handshake. The hardware exposes a single shared > 16-register scratchpad bank split into two disjoint 8-register sets > (one per side), so the driver uses a packed handshake layout that > fits in 8 registers, plugged in through the dev_handshake and > read_peer_config hooks. > > - Outbound translation window. AMD NTB uses an outbound translation > window: a write to a BARxx memory-window offset is forwarded to > (xlat_base | offset) in the peer's memory rather than > (xlat_base + offset). The translation base must therefore be aligned > to a power of two >= the window length so that no offset bit collides > with a set bit in the base. This is reported to applications through a > new mw_addr_align field in struct ntb_dev_info and honoured by the ntb > example when reserving the memory window memzone. > > - Secondary-side link status. On the secondary side the device's own > PCIe link status does not reflect the true inter-host link, so the > speed and width are read from the upstream switch port via sysfs. > > Tested on a two-node setup (primary + secondary EPYC Embedded hosts) > with the dpdk-ntb example: the link comes up at the expected speed and > width on both sides, and file transfers are byte-correct end to end for > both small and large files. > > Raghavendra Ningoji (3): > raw/ntb: generalize framework for multiple vendors > raw/ntb: add AMD NTB support > doc: add AMD NTB support > > MAINTAINERS | 1 + > doc/guides/rawdevs/ntb.rst | 18 +- > doc/guides/rel_notes/release_26_11.rst | 8 + > drivers/raw/ntb/meson.build | 3 +- > drivers/raw/ntb/ntb.c | 115 ++-- > drivers/raw/ntb/ntb.h | 18 + > drivers/raw/ntb/ntb_hw_amd.c | 709 +++++++++++++++++++++++++ > drivers/raw/ntb/ntb_hw_amd.h | 114 ++++ > drivers/raw/ntb/rte_pmd_ntb.h | 10 + > examples/ntb/ntb_fwd.c | 22 +- > usertools/dpdk-devbind.py | 4 +- > 11 files changed, 985 insertions(+), 37 deletions(-) > create mode 100644 drivers/raw/ntb/ntb_hw_amd.c > create mode 100644 drivers/raw/ntb/ntb_hw_amd.h
We need a review on this series to make sure nothing gets broken by those additions. In terms of timeline, such updates are welcome in rc1, but this can slide to rc2 window. https://core.dpdk.org/roadmap/#dates Thank you. -- David Marchand
