RE: [RFC v3 1/3] eal/lcore: add topology based functions

["Varghese, Vipin" <Vipin.Varghese@amd.com>]

Snipped

> 
> 
> > > > > Does the API need to be prepared for L4 cache?
> > > > > https://www.anandtech.com/show/16924/did-ibm-just-preview-the-
> > future
> > > > > -
> > > > of-caches
> > > > Thank you for the pointer, yes initial patch was considering L4
> > cache
> > > > too. But I was not able to get hold of system or get someone to
> > test
> > > > this with L4.
> > > > Hence removed the L4 instance from dpdk_topology structure.
> > > >
> > > > We can introduce into v4. Can we get someone from IBM to confirm
> > the
> > > > same?
> > >
> > > If any of the CPU folks think L4 cache might become relevant in the
> > foreseeable
> > > future, it should be added to the API without testing at this time.
> >
> > I remember 3 L4 cache scenario
> >  1. from IBM power-9 variant suggested in 2020-2021 in hot chips  2.
> > from Intel
> >   a. Haswell|Broadwell series with eDram as L4
> >   b. future product (at least in desktop) with L4 cache.
> >
> > > Adding it now would prevent API breakage whenever L4 cache actually
> > becomes relevant.
> > > Otherwise please don't support for it - considering it would be dead
> > and untested
> > > code.
> >
> > I can add the same to the DPDK topology probe in v4, on AMD EPYC v-
> > cache is treated as extended L3 and not L4. Hence will not be able to
> > test on AMD EPYC.
> 
> I recall from the Cache Stashing community call... There is some ACPI function to
> get the (opaque) "location IDs" of various parts in the system, to be used for setting
> the Cache Stashing hints.
> Is there only one "ACPI location ID" (I don't know the correct name) shared by the
> L3 cache and the v-cache in AMD EPYC, or do they have each their own?

At least on AMD EPYC, the stashing ID updated to either MSI-X table or Device Specific Mode is core-id.


> If they are not exposed as one ID, but two separate IDs, the Topology API might
> need to reflect this, so it can be used in the Cache Stashing API.

I have different view on the same and had shared this with Ajit (Broadcom) and others. To my understanding, use of rte_ethdev API used
for caching hints should be inline to rte_lcore. Depending upon the platform (ARM's specific implementation, the lcore gets translated to L2 or L3 cache ID within the PMD.

Note:  the current patch introduces of Topology aware grouping, which helps to run application better or tiles or chiplets sharing same L2|L3 or IO domain.

Snipped