On Mon, 28 Sept 2026 at 12:50, 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 so other vendors can reuse the common code, and > patch 2 adds the AMD hardware driver together with its documentation. > > 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 > the new rte_pmd_ntb_get_mem_align() API 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. > > Changes since v1: > > - Replaced the mw_addr_align field in struct ntb_dev_info with a > mem_align op and the rte_pmd_ntb_get_mem_align() API, so the > base-address alignment computation lives in the driver and the > application just queries it. The ntb example no longer open-codes the > power-of-two/alignment logic (Bruce Richardson's review of patch 2). > > - Squashed the documentation, release note and MAINTAINERS update into > the AMD driver patch, and documented the alignment API in the guide > (2 patches instead of 3). > > - Minor meson.build formatting cleanup (trailing comma). > > - Patch 1 keeps the ntb_dev_ops hooks (interrupt_handler, dev_handshake, > read_peer_config) as optional, with the built-in scratchpad path used > when a hook is NULL, as discussed on the v1 thread.
I took some time to look at this driver. - (even before this series) the driver is riddled with runtime checks on the ntb_ops presence. As far as I can see, none of those checks are required and those really make the code confusing. Instead, all ops should be enforced at probing time when selecting the vendor ops. This could be a first preparation commit. - The handshake op should be mandatory and provided by both Intel and AMD implementations. This probably makes the mw_set_trans op a vendor specific concern which does not have to be exposed as a op. - I see no reason to have a separate interrupt handler. This should stay in common code. It just needs some abstractions of some operations: - read_peer_config (which is present in this series), - peer_mw_validate (which can be easily abstracted from the current handshake handler), - link_cleanup (idem, can be abstracted from existing code), - Only handle_hw_event seems optional, and it is better to keep optional ops to a minimum, this reduces the runtime checks. There is some rebase needed on the RN, and the dpdk-devbind.py (trivial). Please make sure to send a series freshly rebased so that CI can pass on next revision (did not happen on v2). -- David Marchand
