Hi Stephen, > There is a fundamental conflict with the increasing growth of "nerd knobs" > like this in the DPDK. Users already have problems understanding DPDK and > adding more complexity does not help. > > So any new feature like this should be: > 1. Just work right without any configuration. It can't suck by default. > By default, this feature is disabled. It can be only enabled by calling the following at the queue setup time. rte_eth_dev_stashing_rx_config_set rte_eth_dev_stashing_tx_config_set
It's unlikely for someone not familiar with TPH to call these functions. The performance for them should be as good as without this feature. > 2. The API's should be used in the drivers and core, not exposed up > to the application. Most of the hot data structures are in the > drivers now. > PMDs don't know which CPU and cache level to use with TPH. That information needs to be conveyed to the PMD, for it to work. Please suggest alternatives. > 3. Fit into existing API models. Like rte_prefetch(). > PCIe TPH is a hint from a PCIe device to the system interconnect to push data into CPU caches. I cannot think of an existing API that matches the semantics of TPH. rte_prefetch() is a hint to the CPU from the application, something totally different. > Is the goal of DPDK enabling high speed applications, or enabling vendor > benchmarks? This is a vendor agnostic feature from the PCI-SIG implemented by almost every hardware vendor in their NICs and SoCs. FYI: Kernel patch - https://patchwork.kernel.org/project/linux-pci/patch/20240927215653.1552411-2-wei.hua...@amd.com/
