From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BB79C45BBB; Thu, 24 Oct 2024 07:49:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8ABCF4028A; Thu, 24 Oct 2024 07:49:33 +0200 (CEST) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by mails.dpdk.org (Postfix) with ESMTP id 223B540264 for ; Thu, 24 Oct 2024 07:49:32 +0200 (CEST) Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-460d1145cd8so3705341cf.3 for ; Wed, 23 Oct 2024 22:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729748971; x=1730353771; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mnD/gdMEObCrN9jrYcRQ+T47RS+OSH+zyQniv1JrhBo=; b=W8w8gkKdYEuJKublozR5D4++v3CKXvfNhshKQjkn8QXRqwdDRri202uIukfAzK08Yr DI5E21dxU9bP1zTV+2Ygdq+4b+1Efl5g0p4Mwo/mqUb+j5ol01tO5CLGVuV+VzSQvbIu OTQvnlKioL9WRvt0Aw9bAYZz8ODjilMT486aiLABhsInY/Ua+uHfKIhlDg8wKRMGjGwv byLz1CwTLcsxBI2GdEPK81K2WFkHmY1Yn6yhYk8IUiBG+uVAihWGXT/FOYOywOSG/iQC vg33vKFZdEJmrCxlTCy8T9LMC3JeCGtX3ZNI3WMsVHQ2WjiSIdpI1ORniFD0GE8ts/Lt FJ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729748971; x=1730353771; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mnD/gdMEObCrN9jrYcRQ+T47RS+OSH+zyQniv1JrhBo=; b=WsKFhCu3NEHjd/L1JO3WZ0plhbQUZMkmJQQr4LF8TIc243zzu7/Mo1MJgCWu85lHlV +8PotZKexUKxG4VGk9KTIc5hfJFqhAYEc2RHi+IWUpRYwMxn1V3HXW9b7iyoqm/8PrGa YTFEJc4rcF+Ta22sgd+P0k3vPbl6qjWuxjMdT1lcYgfW0epQ5W5UTy1Vv7+DjMFRclPJ 8XvmwBTEjMN7+49YSsQOrPsgtRyX9PEuqpAPf4kGAbyqh3ZIWXbAtC1B50VhIIGnxmTh 33MDkwABsR4W5RIOmYys8JSMZRYAdf49dvw4F0OPFQ9APcW9EUu7ybNwMHDDufnN6fZB vW+w== X-Forwarded-Encrypted: i=1; AJvYcCUIZZLkjHTDAA9WCjLnBWBj8Wm3UVTNp193EFd4jzzYMifFue7rx0sFkl19bXTJiw0r0Lg=@dpdk.org X-Gm-Message-State: AOJu0YwcX2ttZz9RvEODepLk9+fyRYHK1slyS0s+n8HfAkVJe+EktZkM EJwnzm8xonRfH0tmK/c0pS5ZFD0Ru/n4rU0GVHmlsiCeKgq4T9EiAMj8TZGt+KdiXtTHgYDdcPy 82vrUUvyhnXzfxMnxjkiFfuy8mTA= X-Google-Smtp-Source: AGHT+IGhWuUPYLHF+ZJ47OX31HfKNuI48UZE6SJp2KISoWElVSv3TMjWH2fIofLKvckX4gm7qeDdkWly35OtUN6l9Iw= X-Received: by 2002:ac8:4a8f:0:b0:461:15a1:788d with SMTP id d75a77b69052e-46115a17ab1mr57791621cf.46.1729748971419; Wed, 23 Oct 2024 22:49:31 -0700 (PDT) MIME-Version: 1.0 References: <20240715221141.16153-1-wathsala.vithanage@arm.com> <20241021015246.304431-1-wathsala.vithanage@arm.com> <20241021015246.304431-3-wathsala.vithanage@arm.com> In-Reply-To: <20241021015246.304431-3-wathsala.vithanage@arm.com> From: Jerin Jacob Date: Thu, 24 Oct 2024 11:19:04 +0530 Message-ID: Subject: Re: [RFC v3 2/2] ethdev: introduce the cache stashing hints API To: Wathsala Vithanage Cc: Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org, nd@arm.com, Honnappa Nagarahalli , Dhruv Tripathi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Oct 21, 2024 at 7:23=E2=80=AFAM Wathsala Vithanage 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 > Reviewed-by: Honnappa Nagarahalli > Reviewed-by: Dhruv Tripathi > > + > +/** 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 pr= ior 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.