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 9FC1742595; Thu, 14 Sep 2023 10:09:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 232AB40293; Thu, 14 Sep 2023 10:09:14 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 82DA840289 for ; Thu, 14 Sep 2023 10:09:12 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 04E55B1D1 for ; Thu, 14 Sep 2023 10:09:12 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 03294B4A8; Thu, 14 Sep 2023 10:09:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -2.3 Received: from [192.168.1.59] (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 ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D2620B713; Thu, 14 Sep 2023 10:09:10 +0200 (CEST) Message-ID: <7a343f4c-bc49-4f35-6518-24c52b09aad8@lysator.liu.se> Date: Thu, 14 Sep 2023 10:09:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: quick thread in DLB2 Content-Language: en-US To: Honnappa Nagarahalli , "Sevincer, Abdullah" , Stephen Hemminger , "thomas@monjalon.net" Cc: "dev@dpdk.org" , Tyler Retzlaff , nd References: <2363761.yKrmzQ4Hd0@thomas> <20230906124526.02c5fe61@hermes.local> <7d0f8f9b-d3a2-d6fb-adad-4be48ff02449@lysator.liu.se> 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 2023-09-13 22:56, Honnappa Nagarahalli wrote: > > >> -----Original Message----- >> From: Mattias Rönnblom >> Sent: Wednesday, September 13, 2023 10:48 AM >> To: Sevincer, Abdullah ; Stephen Hemminger >> ; thomas@monjalon.net >> Cc: dev@dpdk.org; Tyler Retzlaff >> Subject: Re: quick thread in DLB2 >> >> On 2023-09-11 16:28, Sevincer, Abdullah wrote: >>> Mattias, >>> Yes that’s correct. >>> >>> >> >> There is no way to cleaner and more robust way to achieve the same result? >> For example, by accessing /proc, or better, an DPDK abstraction of the same. > There similar issues in other areas. For ex: the CPUs with large core count have larger interconnect. The SLC to CPU distance starts to matter and the memory latency increases. The distance of the cores on the interconnect also impacts lock behaviors. We probably need a common mechanism/library to export such details. To make DSW (and other work schedulers) work better on systems with SMT, it would be useful to know which lcores are hardware thread siblings. Topology related to CPU core capacity in heterogeneous system (e.g., big.LITTLE) could be used for similar purposes. The list goes on but one wouldn't need to address all use cases in the v1 API. Something like hwloc(7), but DPDK native. > Not sure how much of this would be a security risk. > What do have in mind? The DPDK library has no more privileges than the application running on top of it. As far as I see, what we are talking about here is mere convenience and portability, from a security point of view. >> >>> -----Original Message----- >>> From: Mattias Rönnblom >>> Sent: Friday, September 8, 2023 12:28 AM >>> To: Sevincer, Abdullah ; Stephen >>> Hemminger ; Thomas Monjalon >>> >>> Cc: dev@dpdk.org; Tyler Retzlaff >>> Subject: Re: quick thread in DLB2 >>> >>> On 2023-09-08 00:09, Sevincer, Abdullah wrote: >>>> Hi Stephen, >>>> It is probing ports for best CPU. Yes it collects cycles. We may rework in the >> future. >>> >>> Best, in what sense? Is this some kind of topology exploration? One DLB >> port being closer to (cheaper to access for) certain cores? >>> >>>> Open to suggestions. >>>> >>>> -----Original Message----- >>>> From: Stephen Hemminger >>>> Sent: Wednesday, September 6, 2023 12:45 PM >>>> To: Thomas Monjalon >>>> Cc: Sevincer, Abdullah ; dev@dpdk.org; >>>> Tyler Retzlaff >>>> Subject: Re: quick thread in DLB2 >>>> >>>> On Fri, 01 Sep 2023 16:08:48 +0200 >>>> Thomas Monjalon wrote: >>>> >>>>> Hello Abdullah, >>>>> >>>>> In the DLB2 code, I see a thread is created for a single operation: >>>>> In drivers/event/dlb2/pf/base/dlb2_resource.c >>>>> pthread_create(&pthread, NULL, &dlb2_pp_profile_func, >>>>> &dlb2_thread_data[i]); and just after: >>>>> pthread_join(pthread, NULL); >>>>> >>>>> Can we avoid creating this thread? >>>>> I guess no, because it must spawn on a specific CPU. >>>>> >>>>> >>>> >>>> The per thread data seems to break lots of expectations in EAL. >>>> It all seems to be about capturing the number of cycles on different cores. >>>> Looks like a mess.