From: Stephen Hemminger <stephen@networkplumber.org>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>
Cc: Wathsala Vithanage <wathsala.vithanage@arm.com>,
dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>,
Ferruh Yigit <ferruh.yigit@amd.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
nd@arm.com, Dhruv Tripathi <dhruv.tripathi@arm.com>
Subject: Re: [RFC v2] ethdev: an API for cache stashing hints
Date: Wed, 23 Oct 2024 13:18:40 -0700 [thread overview]
Message-ID: <20241023131840.212eb680@hermes.local> (raw)
In-Reply-To: <f95e2d97-c312-4a0d-9182-2cce5d57a4a6@lysator.liu.se>
On Wed, 23 Oct 2024 19:59:35 +0200
Mattias Rönnblom <hofors@lysator.liu.se> wrote:
> > diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> > index 883e59a927..b90dc8793b 100644
> > --- a/lib/ethdev/ethdev_driver.h
> > +++ b/lib/ethdev/ethdev_driver.h
> > @@ -1235,6 +1235,70 @@ typedef int (*eth_count_aggr_ports_t)(struct rte_eth_dev *dev);
> > typedef int (*eth_map_aggr_tx_affinity_t)(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > uint8_t affinity);
> >
> > +/**
> > + * @internal
> > + * Set cache stashing hint in the ethernet device.
> > + *
> > + * @param dev
> > + * Port (ethdev) handle.
> > + * @param cpuid
> > + * ID of the targeted CPU.
> > + * @param cache_level
> > + * Level of the cache to stash data.
>
> 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.
+1 for the concept of having a CPU and PCI topology map that
can be queried by drivers and application. Dumpster diving into sysfs
is hard to get right and keeps growing. I wonder if there exists an open
source library that is a good enough starting point for this already.
prev parent reply other threads:[~2024-10-23 20:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 22:11 Wathsala Vithanage
2024-07-17 2:27 ` Stephen Hemminger
2024-07-18 18:48 ` Wathsala Wathawana Vithanage
2024-07-20 3:05 ` Honnappa Nagarahalli
2024-07-17 10:32 ` Konstantin Ananyev
2024-07-22 11:18 ` Ferruh Yigit
2024-07-26 20:01 ` Wathsala Wathawana Vithanage
2024-09-22 21:43 ` Ferruh Yigit
2024-10-04 17:52 ` Stephen Hemminger
2024-10-04 18:46 ` Wathsala Wathawana Vithanage
2024-10-21 1:52 ` [RFC v3 0/2] An API for Stashing Packets into CPU caches Wathsala Vithanage
2024-10-21 1:52 ` [RFC v3 1/2] pci: introduce the PCIe TLP Processing Hints API Wathsala Vithanage
2024-10-21 1:52 ` [RFC v3 2/2] ethdev: introduce the cache stashing hints API Wathsala Vithanage
2024-10-21 7:36 ` Morten Brørup
2024-10-21 7:35 ` [RFC v3 0/2] An API for Stashing Packets into CPU caches Chenbo Xia
2024-10-21 12:01 ` Wathsala Wathawana Vithanage
2024-10-22 1:12 ` Stephen Hemminger
2024-10-22 18:37 ` Wathsala Wathawana Vithanage
2024-10-22 21:23 ` Stephen Hemminger
2024-10-23 17:59 ` [RFC v2] ethdev: an API for cache stashing hints Mattias Rönnblom
2024-10-23 20:18 ` Stephen Hemminger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241023131840.212eb680@hermes.local \
--to=stephen@networkplumber.org \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=dhruv.tripathi@arm.com \
--cc=ferruh.yigit@amd.com \
--cc=hofors@lysator.liu.se \
--cc=nd@arm.com \
--cc=thomas@monjalon.net \
--cc=wathsala.vithanage@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).