Re: [RFC 0/2] introduce LLC aware functions

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

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

-- 
Thanks,
Anatoly