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 F18DA4596F; Thu, 12 Sep 2024 17:50:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D0F9E4029B; Thu, 12 Sep 2024 17:50:10 +0200 (CEST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by mails.dpdk.org (Postfix) with ESMTP id 9188C4028F for ; Thu, 12 Sep 2024 17:50:09 +0200 (CEST) Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-7191901abd6so723864b3a.3 for ; Thu, 12 Sep 2024 08:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1726156208; x=1726761008; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=MOFvWZCNKNpkZlGdVp+ZCy0RlukCDmOaAsKjaDfUTag=; b=XhBCsTywCbG6nF34R0QCrUvd5J201rdL2B63r3dY5KfxaLPekAQ4UaPv8cggMwIrcH 6hm6V3mzN+GJvCl+OqHxJC+ajJh2Ilfmg7lOu5LDktZ7SAIwD64IPs23EHwpdbSyvLhu sSLB8z32pLCpYzOySsMAcKD6TM1NKpKHoSSS9s1yI+GmQC1KieogSIiQl8l5lOTgsUTw OJpRTvoKAN7NuM7iM+BPSHayebJITEkByHRCP6cZSHF1zE2dfn648D/0hN6/m0Yn+H+y gDOpQzx08uGIV0lZB5g7WckipQYWhaFj6DDPlG/oveyZ6T94AkK4gJC3JCAf96KZ34JT fx+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726156208; x=1726761008; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MOFvWZCNKNpkZlGdVp+ZCy0RlukCDmOaAsKjaDfUTag=; b=BqeBSIi58gMuY18fY6dGroA2Y+P0Qh9qzv+2xWB5wk+BS+zwyqIBbOeP8zOFdukt8s 8jL2WELxOsvtJGlsOti6P0BbAmpKjiRxvkL4QHAu76mN8fKVsrF1CKH1TE4c+gBrknqE w/0jXeUanzY2SdTU80b7XwRLsE+ja19ho4r9sMysyX0HZCtfccaU92Xb7zSil6CO3ndy HLgzwNL0xJB8G10BXNllb5Hfz6Mw6PR7T1QjQ5qg5dPx+DN4Jq6M62+Xj9/0cVFYRs+g EVcEs93HkCEpvxNhbSg5s8Vwx1b1A/86Hb5FcczIcS4hghSlq40CpThc85yNV029sm3S GpCA== X-Forwarded-Encrypted: i=1; AJvYcCVIX/LfXyya68+VNjdNcSDEc4lCrB88nD8PvaujwE3iw1TGWSsCm36YIbkPTaBsawMUzi0=@dpdk.org X-Gm-Message-State: AOJu0Yw2OU6jzodeSWwfgDY9c7x1+ReAZ7OLnlVEmO8DzvLic1Q+lzZj S7q9hdsD6BF55Nj9tNxn9vIh3pMEguErjSnBNRwpaB/MRW5L8rKJ+TmMICwYqB8= X-Google-Smtp-Source: AGHT+IHsugWjyjxd8NV85OXK+pC+LJXvt1X5zAscYmz9IMS7V0GzqWgejCpuA8l5fq+i+zemdcVh0g== X-Received: by 2002:a05:6a00:3982:b0:718:d94b:4b with SMTP id d2e1a72fcca58-71926065b0fmr5586131b3a.6.1726156208395; Thu, 12 Sep 2024 08:50:08 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71908fca29fsm4738470b3a.44.2024.09.12.08.50.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Sep 2024 08:50:08 -0700 (PDT) Date: Thu, 12 Sep 2024 08:50:06 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: "Varghese, Vipin" , Honnappa Nagarahalli , "Yigit, Ferruh" , "dev@dpdk.org" , nd Subject: Re: [RFC 0/2] introduce LLC aware functions Message-ID: <20240912085006.67011a2b@hermes.local> In-Reply-To: <7a83997e-cf35-458d-9d86-ba3ed7a4e27d@lysator.liu.se> 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> <7a83997e-cf35-458d-9d86-ba3ed7a4e27d@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Thu, 12 Sep 2024 14:12:55 +0200 Mattias R=C3=B6nnblom wrote: > On 2024-09-12 13:23, Varghese, Vipin wrote: > > [Public] > >=20 > > Snipped =20 > >>=20 > >>=20 > >> To to be clear; it's something like this I think of when I say "DOM-st= yle" API. > >>=20 > >> #ifndef RTE_HWTOPO_H > >> #define RTE_HWTOPO_H > >>=20 > >> struct rte_hwtopo_node; > >>=20 > >> enum rte_hwtopo_node_type { > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RTE_HWTOPO_NODE_TYPE_CPU_CORE, > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RTE_HWTOPO_NODE_TYPE_CACHE, > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RTE_HWTOPO_NODE_TYPE_NUMA > >> }; > >>=20 > >> int > >> rte_hwtopo_init(void); > >>=20 > >> struct rte_hwtopo_node * > >> rte_hwtopo_get_core_by_lcore(unsigned int lcore); > >>=20 > >> struct rte_hwtopo_node * > >> rte_hwtopo_get_core_by_id(unsigned int os_cpu_id); > >>=20 > >> struct rte_hwtopo_node * > >> rte_hwtopo_parent(struct rte_hwtopo_node *node); > >>=20 > >> struct rte_hwtopo_node * > >> rte_hwtopo_first_child(struct rte_hwtopo_node *node); > >>=20 > >> struct rte_hwtopo_node * > >> rte_hwtopo_next_child(struct rte_hwtopo_node *node, > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct rte_= hwtopo_node *child); > >>=20 > >> struct rte_hwtopo_node * > >> rte_hwtopo_first_sibling(struct rte_hwtopo_node *node); > >>=20 > >> struct rte_hwtopo_node * > >> rte_hwtopo_next_sibling(struct rte_hwtopo_node *node, > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= struct rte_hwtopo_node *child); > >>=20 > >> enum rte_hwtopo_node_type > >> rte_hwtopo_get_type(struct rte_hwtopo_node *node); > >>=20 > >> #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 > >>=20 > >> int > >> rte_hwtopo_get_attr_int64(struct rte_hwtopo_node *node, unsigned int > >> attr_name, > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 int64_t *attr_value); > >>=20 > >> int > >> rte_hwtopo_get_attr_str(struct rte_hwtopo_node *node, unsigned int > >> attr_name, > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= char *attr_value, size_t capacity); > >>=20 > >> #endif > >>=20 > >> Surely, this too would be awkward (or should I say cumbersome) to use = in certain scenarios. =20 > > This appears to be more like hwloc api calls, as shared in my earlier=20 > > email my intention with the API suggestion is not introduce new library. > > I have certain reservations and with my current understanding I am not= =20 > > able to map certain DPDK core mapping. Let discuss this in technical ca= ll. > > Snipped =20 >=20 > It still would need to be a part of EAL (so not a new library), since=20 > EAL surely would depend on it (sooner rather than later). >=20 > If this functionality should be a new library, or a new API in an=20 > existing library, it doesn't really matter if your original intentions=20 > where something else, does it. >=20 Good discussion. I wonder if the API would be cleaner if it just provided a tree representat= ion 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 mo= re 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.