DPDK patches and discussions
 help / color / mirror / Atom feed
From: Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Chenbo Xia <chenbox@nvidia.com>,
	Nipun Gupta <nipun.gupta@amd.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>,
	Gaetan Rivet <grive@u256.net>, "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: [PATCH v5 2/4] bus/pci: introduce the PCIe TLP Processing Hints API
Date: Thu, 5 Jun 2025 14:32:10 +0000	[thread overview]
Message-ID: <PAWPR08MB8909292833451F5AC40AEE289F6FA@PAWPR08MB8909.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <aEFMU-aeau_WOvCQ@bricha3-mobl1.ger.corp.intel.com>



> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Thursday, June 5, 2025 2:51 AM
> To: Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>
> Cc: Chenbo Xia <chenbox@nvidia.com>; Nipun Gupta <nipun.gupta@amd.com>;
> Anatoly Burakov <anatoly.burakov@intel.com>; Gaetan Rivet <grive@u256.net>;
> dev@dpdk.org; nd <nd@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; Dhruv Tripathi <Dhruv.Tripathi@arm.com>
> Subject: Re: [PATCH v5 2/4] bus/pci: introduce the PCIe TLP Processing Hints API
> 
> On Wed, Jun 04, 2025 at 10:52:24PM +0000, Wathsala Wathawana Vithanage
> wrote:
> > > > rte_pci_tph_st_{get, set} functions will return an error if
> > > > processing any of the rte_tph_info objects fails. The API does not
> > > > indicate which entry in the rte_tph_info array was executed
> > > > successfully and which caused an error. Therefore, in case of an
> > > > error, the caller should discard the output. If rte_pci_tph_set
> > > > returns an error, it should be treated as a partial error. Hence,
> > > > the steering-tag update on the device should be considered partial
> > > > and inconsistent with the expected
> > > outcome.
> > > > This should be resolved by resetting the endpoint device before
> > > > further attempts to set steering tags.
> > >
> > > This seems very clunky for the user. Is there a fundamental reason
> > > why we cannot report out what ones passed or failed?
> > >
> > > If it's a limitation of the kernel IOCTL, how about just making one
> > > ioctl for each individual op requested, one at a time. That way we
> > > will know what failed to report it?
> > >
> >
> > The V1 of the kernel patch had that feature, but it was frowned upon,
> > and I was asked to implement the IOCTL this way. Please find it here
> > (V1)
> > https://lore.kernel.org/kvm/20250221224638.1836909-1-wathsala.vithanag
> > e@arm.com/T/#me73cf9b9c87da97d7d9461dfb97863b78ca1755b
> >
> > > Other comments inline below.
> > >
> >
> > I will address them in the next version.
> >
> > Thanks.
> >
> > --wathsala
> >
> > > /Bruce
> > >
> 
> <snip>
> 
> > > > diff --git a/lib/pci/rte_pci.h b/lib/pci/rte_pci.h index
> > > > 9a50a12142..da9cd666bf 100644
> > > > --- a/lib/pci/rte_pci.h
> > > > +++ b/lib/pci/rte_pci.h
> > > > @@ -137,6 +137,21 @@ extern "C" {
> > > >  /* Process Address Space ID (RTE_PCI_EXT_CAP_ID_PASID) */
> > > >  #define RTE_PCI_PASID_CTRL		0x06    /* PASID control register
> */
> > > >
> > > > +/* TPH Requester */
> > > > +#define RTE_PCI_TPH_CAP            4       /* capability register */
> > > > +#define RTE_PCI_TPH_CAP_ST_NS      0x00000001 /* No ST Mode
> Supported
> > > */
> > > > +#define RTE_PCI_TPH_CAP_ST_IV      0x00000002 /* Interrupt Vector
> Mode
> > > Supported */
> > > > +#define RTE_PCI_TPH_CAP_ST_DS      0x00000004 /* Device Specific
> Mode
> > > Supported */
> > > > +#define RTE_PCI_TPH_CAP_EXT_TPH    0x00000100 /* Ext TPH Requester
> > > Supported */
> > > > +#define RTE_PCI_TPH_CAP_LOC_MASK   0x00000600 /* ST Table Location
> */
> > > > +#define RTE_PCI_TPH_LOC_NONE       0x00000000 /* Not present */
> > > > +#define RTE_PCI_TPH_LOC_CAP        0x00000200 /* In capability */
> > > > +#define RTE_PCI_TPH_LOC_MSIX       0x00000400 /* In MSI-X */
> > > > +#define RTE_PCI_TPH_CAP_ST_MASK    0x07FF0000 /* ST Table Size */
> > > > +#define RTE_PCI_TPH_CAP_ST_SHIFT   16      /* ST Table Size shift */
> > > > +#define RTE_PCI_TPH_BASE_SIZEOF    0xc     /* Size with no ST table */
> > > > +
> > > > +
> > >
> > > Where are all these values used? They don't seem to be needed by
> > > this patch. If needed in later patches, I'd suggest adding them there.
> > >
> >
> > RTE_PCI_TPH_CAP_ST_NS, RTE_PCI_TPH_CAP_ST_IV and
> RTE_PCI_TPH_CAP_ST_DS
> > are used by drivers. I40e patch uses RTE_PCI_TPH_CAP_ST_DS.
> > I will remove the rest, added here for completeness.
> >
> 
> Having them all for completeness is fine. You can keep this as-is in next version
> then.
> 

+1

--wathsala
> /Bruce

  reply	other threads:[~2025-06-05 14:32 UTC|newest]

Thread overview: 61+ 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-12-03 20:54     ` Stephen Hemminger
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
2024-12-03 21:13     ` Stephen Hemminger
2024-12-05 15:40       ` David Marchand
2024-12-05 21:00         ` Stephen Hemminger
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
2025-05-17 15:17   ` [RFC PATCH v4 0/3] " Wathsala Vithanage
2025-05-17 15:17     ` [RFC PATCH v4 1/3] pci: add non-merged Linux uAPI changes Wathsala Vithanage
2025-05-19  6:41       ` David Marchand
2025-05-19 17:55         ` Wathsala Wathawana Vithanage
2025-05-17 15:17     ` [RFC PATCH v4 2/3] bus/pci: introduce the PCIe TLP Processing Hints API Wathsala Vithanage
2025-05-19  6:44       ` David Marchand
2025-05-19 17:57         ` Wathsala Wathawana Vithanage
2025-05-17 15:17     ` [RFC PATCH v4 3/3] ethdev: introduce the cache stashing hints API Wathsala Vithanage
2025-05-20 13:53       ` Stephen Hemminger
2025-06-02 22:38   ` [PATCH v5 0/4] An API for Cache Stashing with TPH Wathsala Vithanage
2025-06-02 22:38     ` [PATCH v5 1/4] pci: add non-merged Linux uAPI changes Wathsala Vithanage
2025-06-02 23:11       ` Wathsala Wathawana Vithanage
2025-06-02 23:16         ` Wathsala Wathawana Vithanage
2025-06-04 20:43       ` Stephen Hemminger
2025-06-02 22:38     ` [PATCH v5 2/4] bus/pci: introduce the PCIe TLP Processing Hints API Wathsala Vithanage
2025-06-03  8:11       ` Morten Brørup
2025-06-04 16:54       ` Bruce Richardson
2025-06-04 22:52         ` Wathsala Wathawana Vithanage
2025-06-05  7:50           ` Bruce Richardson
2025-06-05 14:32             ` Wathsala Wathawana Vithanage [this message]
2025-06-05 10:18           ` Bruce Richardson
2025-06-05 14:25             ` Wathsala Wathawana Vithanage
2025-06-05 10:30       ` Bruce Richardson
2025-06-02 22:38     ` [PATCH v5 3/4] ethdev: introduce the cache stashing hints API Wathsala Vithanage
2025-06-03  8:43       ` Morten Brørup
2025-06-05 10:03       ` Bruce Richardson
2025-06-05 14:30         ` Wathsala Wathawana Vithanage
2025-06-02 22:38     ` [PATCH v5 4/4] net/i40e: enable TPH in i40e Wathsala Vithanage
2025-06-04 16:51     ` [PATCH v5 0/4] An API for Cache Stashing with TPH Stephen Hemminger
2025-06-04 22:24       ` Wathsala Wathawana Vithanage
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
2024-10-25  7:43   ` Andrew Rybchenko

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=PAWPR08MB8909292833451F5AC40AEE289F6FA@PAWPR08MB8909.eurprd08.prod.outlook.com \
    --to=wathsala.vithanage@arm.com \
    --cc=Dhruv.Tripathi@arm.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=chenbox@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=grive@u256.net \
    --cc=nd@arm.com \
    --cc=nipun.gupta@amd.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).