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

[Varghese, Vipin]

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.

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