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

["Mattias Rönnblom" <hofors@lysator.liu.se>]

On 2024-09-12 13:23, Varghese, Vipin wrote:
> [Public]
> 
> Snipped
>> 
>> 
>> To to be clear; it's something like this I think of when I say "DOM-style" API.
>> 
>> #ifndef RTE_HWTOPO_H
>> #define RTE_HWTOPO_H
>> 
>> struct rte_hwtopo_node;
>> 
>> enum rte_hwtopo_node_type {
>>      RTE_HWTOPO_NODE_TYPE_CPU_CORE,
>>      RTE_HWTOPO_NODE_TYPE_CACHE,
>>      RTE_HWTOPO_NODE_TYPE_NUMA
>> };
>> 
>> int
>> rte_hwtopo_init(void);
>> 
>> struct rte_hwtopo_node *
>> rte_hwtopo_get_core_by_lcore(unsigned int lcore);
>> 
>> struct rte_hwtopo_node *
>> rte_hwtopo_get_core_by_id(unsigned int os_cpu_id);
>> 
>> struct rte_hwtopo_node *
>> rte_hwtopo_parent(struct rte_hwtopo_node *node);
>> 
>> struct rte_hwtopo_node *
>> rte_hwtopo_first_child(struct rte_hwtopo_node *node);
>> 
>> struct rte_hwtopo_node *
>> rte_hwtopo_next_child(struct rte_hwtopo_node *node,
>>                       struct rte_hwtopo_node *child);
>> 
>> struct rte_hwtopo_node *
>> rte_hwtopo_first_sibling(struct rte_hwtopo_node *node);
>> 
>> struct rte_hwtopo_node *
>> rte_hwtopo_next_sibling(struct rte_hwtopo_node *node,
>>                         struct rte_hwtopo_node *child);
>> 
>> enum rte_hwtopo_node_type
>> rte_hwtopo_get_type(struct rte_hwtopo_node *node);
>> 
>> #define RTE_HWTOPO_NODE_ATTR_CORE_FREQUENCY_NOMINAL 0 #define
>> RTE_HWTOPO_NODE_ATTR_CACHE_LEVEL 1 #define
>> RTE_HWTOPO_NODE_ATTR_CACHE_SIZE 2
>> 
>> int
>> rte_hwtopo_get_attr_int64(struct rte_hwtopo_node *node, unsigned int
>> attr_name,
>>                           int64_t *attr_value);
>> 
>> int
>> rte_hwtopo_get_attr_str(struct rte_hwtopo_node *node, unsigned int
>> attr_name,
>>                         char *attr_value, size_t capacity);
>> 
>> #endif
>> 
>> Surely, this too would be awkward (or should I say cumbersome) to use in certain scenarios. 
> This appears to be more like hwloc api calls, as shared in my earlier 
> email my intention with the API suggestion is not introduce new library.
> I have certain reservations and with my current understanding I am not 
> able to map certain DPDK core mapping. Let discuss this in technical call.
> Snipped

It still would need to be a part of EAL (so not a new library), since 
EAL surely would depend on it (sooner rather than later).

If this functionality should be a new library, or a new API in an 
existing library, it doesn't really matter if your original intentions 
where something else, does it.