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

["Morten Brørup" <mb@smartsharesystems.com>]

> > > > 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?
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.

> 
> >
> > >
> > > >
> > > > And - just a thought:
> > > > Since this library and the Cache Stashing (PCIe TLP) library are
> > > somewhat related,
> > > > would it be beneficial to combine them into one patch series,
> > > primarily to make their
> > > > APIs more uniform?
> > >
> > > There was initial zoom invite for understanding and usage, we
> expected
> > > a follow up on the same to close the loop.
> > > Based on my current understanding, the API to be used as hints to
> PMD
> > > should be passing `lcore id` only.
> > > Hence these can be independent.
> >
> > The Cache Stashing hints API uses a more specific destination than
> just "lcore id".
> > The implementations of this Topology library and the Cache Stashing
> library may be
> > completely independent, but the structure describing a location in
> the topology could
> > be common.
> Thank you, now I understand,
> 
> >
> > Maybe I should say this differently:
> > Wathsala and other folks working on the Cache Stashing API, you need
> to keep a
> > close eye on this Topology patch series!
> > We might expect the Cache Stashing API to reuse relevant structures
> from it.