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 57EC845903; Wed, 4 Sep 2024 16:37:24 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D6A3D4025A; Wed, 4 Sep 2024 16:37:23 +0200 (CEST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mails.dpdk.org (Postfix) with ESMTP id 33D4A4014F for ; Wed, 4 Sep 2024 16:37:22 +0200 (CEST) Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-7140ff4b1e9so5103910b3a.3 for ; Wed, 04 Sep 2024 07:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1725460641; x=1726065441; 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=xY+T+/Gmb6ZJx++vF7O7nNdlvrrB+3A9FffKflgPWQI=; b=2KprUmUs+OpyK4h6C2T5TgU0rd9oDY5nmnUDj42wemKwAabf8kfopw1o8oYkJ9xEwl B1X5EX7qM3K0yn3rhuGAkJWH4/4C0DnnH6oxn9bW4oBH5VMzW/5cqUu1y89w9rg5FRC6 T2+A9/m7p8UtRC32K3W72Z6j4PZJSxKXepnn2X4y4qrpW95jyqvdkquWy2DghCx9wELV WXbSAgkQSmFoZjkc+SCau9ckG89Q1TfF1K32NkxImMhbQTp/grSHO6rVhPUrNA3GvT7v ZPPql90JD0rVECsy8wdQy14Gch84jF7ih2MS131aH4ngRypX4CDSY1XaJEU+mr/XTrld iU+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725460641; x=1726065441; 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=xY+T+/Gmb6ZJx++vF7O7nNdlvrrB+3A9FffKflgPWQI=; b=m5B1CckXSDKqp3YHVjVV5RvFnd3WQB1OVYEalMWfOmIMuaCfp19QH+kDea6MrMlAFG PoUCBS23OnPeVetXzrZj5SKE0yJU/XsWGct6iA7QrhFoIW/InLUL/45txmBnRVIqY6cs pishmijPhIQ2aFMdFNjbpVxtq0em+/dOMMCYrcRwD/6RPE1SK8JVfx6XI7zCSHuuxCwl W5kx5F5cNAHvi7lr/u+pZXFpVIsxGb9oGpeJvLG0nbnUWGLhgJ5Zil6V92DgHUGK1XKX Pc4N9FDY4Nd3nNhnRhtoMN/MAW3cjWNzSBphrD35/qeTJG6jYJwVBCCElQTVXiSGycHH o6/A== X-Forwarded-Encrypted: i=1; AJvYcCX1AOmZR7RtXV9oTstdoY2G+EYvnyifBAyCVSmMM2JxGWG0chD8qJAydmL4gxZAmkIfWXY=@dpdk.org X-Gm-Message-State: AOJu0YwBFEEUpu3YgVRxZMKzdrDXg1SOeEm9OI8M6BnqJDGPCbt0Rt+n AXG4IbFHWGiRz1i573gJ/kITwjUVF9ifw5b58DOeCxSW4Q0yoHNLSS6rjBJi0oE= X-Google-Smtp-Source: AGHT+IFMUq4+Ylmkz58JVnzfbdfGL9qUCnQgndEzny8P/TiGLDUBX/YcdTAbNYf/jc/Pg1rjoyQ4fQ== X-Received: by 2002:a05:6a00:3a05:b0:710:5825:5ba0 with SMTP id d2e1a72fcca58-7173c1e0e87mr12635128b3a.3.1725460641051; Wed, 04 Sep 2024 07:37:21 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71778522fc3sm1744428b3a.13.2024.09.04.07.37.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 07:37:20 -0700 (PDT) Date: Wed, 4 Sep 2024 07:37:19 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: "Varghese, Vipin" , ferruh.yigit@amd.com, dev@dpdk.org Subject: Re: [RFC 0/2] introduce LLC aware functions Message-ID: <20240904073719.0603b2a5@hermes.local> In-Reply-To: References: <20240827151014.201-1-vipin.varghese@amd.com> <45f26104-ad6c-4e42-8446-d8b51ac3f2dd@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 Wed, 4 Sep 2024 11:30:59 +0200 Mattias R=C3=B6nnblom wrote: > On 2024-09-02 02:39, Varghese, Vipin wrote: > > > >=20 > > Thank you Mattias for the comments and question, please let me try to=20 > > explain the same below > > =20 > >> We shouldn't have a separate CPU/cache hierarchy API instead? =20 > >=20 > > Based on the intention to bring in CPU lcores which share same L3 (for= =20 > > better cache hits and less noisy neighbor) current API focuses on using > >=20 > > Last Level Cache. But if the suggestion is `there are SoC where L2 cach= e=20 > > are also shared, and the new API should be provisioned`, I am also > >=20 > > comfortable with the thought. > > =20 >=20 > Rather than some AMD special case API hacked into , I think= =20 > we are better off with no DPDK API at all for this kind of functionality. >=20 > A DPDK CPU/memory hierarchy topology API very much makes sense, but it=20 > should be reasonably generic and complete from the start. Agreed. This one of those cases where the existing project hwloc which is part of open-mpi is more complete and well supported. It supports multiple OS's and can deal with more quirks. https://github.com/open-mpi/hwloc