> If we had a hwtopo API in DPDK, we could just use a node id in such a graph > (of CPUs and caches) to describe were the data ideally would land. > In such a case, you could have a node id for DDR as well, and thus you could > drop the notion of "stashing". Just a "drop off the data here, please, if you > can" API. > > I don't think this API and its documentation should talk about what the "CPU" > needs, since it's somewhat misleading. > > For example, you can imagine you want the packet payload to land in the LLC, > even though it's not for any CPU to consume, in case you know with some > certaintly that the packet will soon be transmitted (and thus consumed by the > NIC). > > The same scenario can happen, the consumer is an accelerator (e.g., a crypto > engine). > > Likewise, you may know that the whole packet will be read by some CPU core, > but you also know the system tends to buffer packets before they are being > processed. In such a case, it's better to go to DRAM right away, to avoid > trashing the LLC (or some other cache). > > Also, why do you need to use the word "host"? Seems like a PCI thing. > This may be implemented in PCI, but surely can be done (and has been > done) without PCI. >
Thanks, Mattias. V2 is outdated, please provide feedback on V3.
