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 4121E45BB6; Wed, 23 Oct 2024 22:18:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CCF4440261; Wed, 23 Oct 2024 22:18:45 +0200 (CEST) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by mails.dpdk.org (Postfix) with ESMTP id 0C54040144 for ; Wed, 23 Oct 2024 22:18:43 +0200 (CEST) Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-83aff992087so6653339f.3 for ; Wed, 23 Oct 2024 13:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1729714723; x=1730319523; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=CYag58s6Fg1lqpcu5ybnHKweh76it8tmTBc7ZF4y4kg=; b=wMT16WZU2cFAnZ/j+5DzjZZrDKZePqz/fjeKwUUExJoXCZWJoE8G4Nzhecmha+5L8o rUfI6gsU0txZ571lGhM+zhuWZdsaaW/TBDlBiUwefeIvSZsEOymsio18lRXTTlL887hP QjxiGpVztnGRp5V/elQN/XmI+APftVj74EB9lHrVASAuvVZPtjJHF4yGTsB7nlEidsqW 59Rcrp1MuruTLF4gWqmbZyK9xhRf0fk5iDohtyqEtlN/FaU5RSl0TUWOVvTu16QMEjMF nePa9GIulC17D1AfoN8nBdVzO7pR4nroLF2Hbf7KTv28JF7PXUQgOTauPErHHXL+dvBa 9Acg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729714723; x=1730319523; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CYag58s6Fg1lqpcu5ybnHKweh76it8tmTBc7ZF4y4kg=; b=gdHcGY6a7ujv2/4LarUFoIPoZ5lITlT2awP4po8owyM6eshUbkIGtQNOMgAdAeSZFc 7WAcfdKSY83zB09b57kPRBVosr7KV7iZjSUZWkbJ9IBL5ggxJPoFkuT8uWh1RE9OgSGR PN3C4ZnL2TVZGNS4UHvLw6D054m5pKh0ZCNAeEQHxbB3UNKUvWq5qQJ5a0L84LbUdfqQ ishZPQADBzrrAudkIcTSDuybLyq7+Kj244CnhfFbTN3HwOpWKfPTOQiR/Ech7KHz5OvU kKNLA/mzS6bzYbkhS0VnJps/7fE4EJy0MYZqCc5FNQJC0uD8+Ghk7Hg97jJmnXbCKO4M SDVg== X-Forwarded-Encrypted: i=1; AJvYcCV+AGLJT0j7OfYauhG+647y5TLZx5oRAEuhlQ6WFtW1ZKaAsOK6j90TLD4ZGdpJ0ONWmfY=@dpdk.org X-Gm-Message-State: AOJu0YwFvb9edJ92yXIMBHpbeXxXD2CCVCeAzcmJtAOUkRRcGeQZQGcp ucJ6xuRqZh1v/NHViCbrRTgYpXumLKKL8RgdHsNi/vGswsWnOBPzef3n06/Rrx8= X-Google-Smtp-Source: AGHT+IE004pJtQAqPh7CJ7HDav1lVIlUTx9n6QlBjAdfQmOzwpuL/5LAtIAjw0VTqlS+1KIAAPZ3GQ== X-Received: by 2002:a05:6e02:1c07:b0:3a0:985b:ddb4 with SMTP id e9e14a558f8ab-3a4d592c51cmr46313635ab.2.1729714722950; Wed, 23 Oct 2024 13:18:42 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7eaeab35f8dsm7307148a12.31.2024.10.23.13.18.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Oct 2024 13:18:42 -0700 (PDT) Date: Wed, 23 Oct 2024 13:18:40 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Wathsala Vithanage , dev@dpdk.org, Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , nd@arm.com, Dhruv Tripathi Subject: Re: [RFC v2] ethdev: an API for cache stashing hints Message-ID: <20241023131840.212eb680@hermes.local> In-Reply-To: References: <20240715221141.16153-1-wathsala.vithanage@arm.com> MIME-Version: 1.0 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 Wed, 23 Oct 2024 19:59:35 +0200 Mattias R=C3=B6nnblom 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, ui= nt16_t tx_queue_id, > > uint8_t affinity); > > =20 > > +/** > > + * @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. =20 >=20 > If we had a hwtopo API in DPDK, we could just use a node id in such a=20 > graph (of CPUs and caches) to describe were the data ideally would land.= =20 > In such a case, you could have a node id for DDR as well, and thus you=20 > could drop the notion of "stashing". Just a "drop off the data here,=20 > please, if you can" API. >=20 > I don't think this API and its documentation should talk about what the=20 > "CPU" needs, since it's somewhat misleading. >=20 > For example, you can imagine you want the packet payload to land in the=20 > LLC, even though it's not for any CPU to consume, in case you know with=20 > some certaintly that the packet will soon be transmitted (and thus=20 > consumed by the NIC). >=20 > The same scenario can happen, the consumer is an accelerator (e.g., a=20 > crypto engine). >=20 > Likewise, you may know that the whole packet will be read by some CPU=20 > core, but you also know the system tends to buffer packets before they=20 > are being processed. In such a case, it's better to go to DRAM right=20 > away, to avoid trashing the LLC (or some other cache). >=20 > Also, why do you need to use the word "host"? Seems like a PCI thing.=20 > This may be implemented in PCI, but surely can be done (and has been=20 > 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.