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

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 12 Sep 2024 14:12:55 +0200
Mattias Rönnblom <hofors@lysator.liu.se> wrote:

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

Good discussion.
I wonder if the API would be cleaner if it just provided a tree representation
of the hardware in a data structure, instead of trying to provide FOREACH.

The other concern is that hardware will evolve and there is likely to be more
possibilities. It is impossible totally future proof API's (YAGNI) but worth
thinking about it now.

There is also the issue of core's with different clock speeds that should
be represented as well.