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