From: Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
Ferruh Yigit <ferruh.yigit@amd.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
"dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Dhruv Tripathi <Dhruv.Tripathi@arm.com>, nd <nd@arm.com>
Subject: RE: [RFC v3 2/2] ethdev: introduce the cache stashing hints API
Date: Thu, 24 Oct 2024 15:04:49 +0000 [thread overview]
Message-ID: <PAWPR08MB89099E8642E5920C739BBC6A9F4E2@PAWPR08MB8909.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CALBAE1NM3=HeFqR2O85LDvjPSF1kKiYzEmy7aZbgGDYXu8+k5w@mail.gmail.com>
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, October 24, 2024 12:49 AM
> To: Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>
> Cc: thomas@monjalon.net; Ferruh Yigit <ferruh.yigit@amd.com>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; nd
> <nd@arm.com>; Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> Dhruv Tripathi <Dhruv.Tripathi@arm.com>
> Subject: Re: [RFC v3 2/2] ethdev: introduce the cache stashing hints API
>
> On Mon, Oct 21, 2024 at 7:23 AM Wathsala Vithanage
> <wathsala.vithanage@arm.com> wrote:
> >
> > Extend the ethdev library to enable the stashing of different data
> > objects, such as the ones listed below, into CPU caches directly from
> > the NIC.
> >
> > - Rx/Tx queue descriptors
> > - Rx packets
> > - Packet headers
> > - packet payloads
> > - Data of a packet at an offset from the start of the packet
> >
> > The APIs are designed in a hardware/vendor agnostic manner such that
> > supporting PMDs could use any capabilities available in the underlying
> > hardware for fine-grained stashing of data objects into a CPU cache
> > (e.g., Steering Tags int PCIe TLP Processing Hints).
> >
> > The API provides an interface to query the availability of stashing
> > capabilities, i.e., platform/NIC support, stashable object types, etc,
> > via the rte_eth_dev_stashing_capabilities_get interface.
> >
> > The function pair rte_eth_dev_stashing_rx_config_set and
> > rte_eth_dev_stashing_tx_config_set sets the stashing hint (the CPU,
> > cache level, and data object types) on the Rx and Tx queues.
> >
> > PMDs that support stashing must register their implementations with
> > the following eth_dev_ops callbacks, which are invoked by the ethdev
> > functions listed above.
> >
> > - stashing_capabilities_get
> > - stashing_rx_hints_set
> > - stashing_tx_hints_set
> >
> > Signed-off-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
> > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > Reviewed-by: Dhruv Tripathi <dhruv.tripathi@arm.com>
> >
>
> > +
> > +/** Queue type is RX. */
> > +#define RTE_ETH_DEV_RX_QUEUE 0
> > +/** Queue type is TX. */
> > +#define RTE_ETH_DEV_TX_QUEUE 1
> > +
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change, or be removed, without
> > +prior notice
> > + *
> > + * A structure used for configuring the cache stashing hints.
> > + */
> > +struct rte_eth_stashing_config {
> > + /** ID of the Processor/Container the stashing hints are
> > + * applied to
> > + */
> > + uint16_t lcore_id;
> > + /** Set if the target is a CPU containeri.lcore_id will be
> > + * used to derive container ID
> > + */
> > + uint16_t container : 1;
> > + uint16_t padding : 7;
> > + /** Cache level of the CPU specified by the cpu_id the
> > + * stashing hints are applied to
> > + */
> > + uint16_t cache_level : 8;
> > + /** Object types the configuration is applied to
> > + */
> > + uint16_t objects;
> > + /** The offset if RTE_ETH_DEV_STASH_OBJECT_OFFSET bit is set
> > + * in objects
> > + */
> > + off_t offset;
> > +};
> > +
> > +/**@{@name Stashable Rx/Tx queue object types supported by the
> > +ethernet device *@see rte_eth_dev_stashing_capabilities_get
> > + *@see rte_eth_dev_stashing_rx_config_set
> > + *@see rte_eth_dev_stashing_tx_config_set
> > + */
> > +
> > +/**
> > + * Apply stashing hint to data at a given offset from the start of a
> > + * received packet.
> > + */
> > +#define RTE_ETH_DEV_STASH_OBJECT_OFFSET 0x0001
> > +
> > +/** Apply stashing hint to an rx descriptor. */
> > +#define RTE_ETH_DEV_STASH_OBJECT_DESC 0x0002
> > +
> > +/** Apply stashing hint to a header of a received packet. */
> > +#define RTE_ETH_DEV_STASH_OBJECT_HEADER 0x0004
> > +
> > +/** Apply stashing hint to a payload of a received packet. */
> > +#define RTE_ETH_DEV_STASH_OBJECT_PAYLOAD 0x0008
> > +
> > +#define __RTE_ETH_DEV_STASH_OBJECT_MASK 0x000f
> > +/**@}*/
> > +
> > +#define RTE_ETH_DEV_STASH_OBJECTS_VALID(t) \
> > + ((!((t) & (~__RTE_ETH_DEV_STASH_OBJECT_MASK))) && (t))
> > +
>
>
> I think, at one of point of time, we need to extend this to other device class
> like(cryptodev etc) where the data needs to move over bus. In that context, all
> the above symbols better to be in EAL and the device class subsystem(example
> ethdev) gives PMD callback.
+1
I will make that change in the RFC v4.
next prev parent reply other threads:[~2024-10-24 15:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 22:11 [RFC v2] ethdev: an API for cache stashing hints 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-24 5:49 ` Jerin Jacob
2024-10-24 6:59 ` Morten Brørup
2024-10-24 15:12 ` Wathsala Wathawana Vithanage
2024-10-24 15:04 ` Wathsala Wathawana Vithanage [this message]
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
2024-10-24 14:59 ` Wathsala Wathawana Vithanage
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=PAWPR08MB89099E8642E5920C739BBC6A9F4E2@PAWPR08MB8909.eurprd08.prod.outlook.com \
--to=wathsala.vithanage@arm.com \
--cc=Dhruv.Tripathi@arm.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=jerinjacobk@gmail.com \
--cc=nd@arm.com \
--cc=thomas@monjalon.net \
/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).