[AMD Official Use Only - AMD Internal Distribution Only] > > >> Yes, this does help clarify things a lot as to why current NUMA > >> support would be insufficient to express what you are describing. > >> > >> However, in that case I would echo sentiment others have expressed > >> already as this kind of deep sysfs parsing doesn't seem like it would > >> be in scope for EAL, it sounds more like something a > >> sysadmin/orchestration (or the application itself) would do. > >> > >> I mean, in principle I'm not opposed to having such an API, it just > >> seems like the abstraction would perhaps need to be a bit more robust > >> than directly referencing cache structure? Maybe something that > >> degenerates into NUMA nodes would be better, so that applications > >> wouldn't have to *specifically* worry about cache locality but > >> instead have a more generic API they can use to group cores together? > >> > > > > Unfortunately can't cover all usecases by sysadmin/orchestration (as > > graph usecase one above), and definitely too much HW detail for the > > application, that is why we required some programmatic way (APIs) for > > applications. > > > > And we are on the same page that, the more we can get away from > > architecture details in the abstraction (APIs) better it is, overall > > intention is to provide ways to application to find lcores works > > efficiently with each other. > > > > For this what do you think about slightly different API *, like: > > ``` > > rte_get_next_lcore_ex(uint i, u32 flag) ``` > > > > Based on the flag, we can grab the next eligible lcore, for this patch > > the flag can be `RTE_LCORE_LLC`, but options are wide and different > > architectures can have different grouping to benefit most from HW in a > > vendor agnostic way. > > I like the idea, what do you think about this abstraction? > > > > * Kudos to Vipin 😉 > > > > Hi Ferruh, > > In principle, having flags for this sort of thing sounds like a better way to go. I > do like this idea as well! It of course remains to be seen how it can work in > practice but to me it certainly looks like a path worth exploring. > Sharing the new RFC shortly.