From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6B2694596E; Thu, 12 Sep 2024 14:13:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F338740265; Thu, 12 Sep 2024 14:12:59 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id B33FC40144 for ; Thu, 12 Sep 2024 14:12:58 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7878A4BC6 for ; Thu, 12 Sep 2024 14:12:58 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 6D1514AEF; Thu, 12 Sep 2024 14:12:58 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.2 Received: from [192.168.1.86] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D0C844A6F; Thu, 12 Sep 2024 14:12:55 +0200 (CEST) Message-ID: <7a83997e-cf35-458d-9d86-ba3ed7a4e27d@lysator.liu.se> Date: Thu, 12 Sep 2024 14:12:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 0/2] introduce LLC aware functions To: "Varghese, Vipin" , Honnappa Nagarahalli Cc: "Yigit, Ferruh" , "dev@dpdk.org" , nd References: <20240827151014.201-1-vipin.varghese@amd.com> <45f26104-ad6c-4e42-8446-d8b51ac3f2dd@lysator.liu.se> <38d0336d-ea9e-41b3-b3d8-333efb70eb1f@lysator.liu.se> <716375DE-0C2F-4983-934A-144D7DE342C6@arm.com> <50ee2d2f-00c0-488c-a80e-1d3021103060@lysator.liu.se> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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.