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 A7CF743CAA; Thu, 28 Mar 2024 03:19:30 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8DF52402CE; Thu, 28 Mar 2024 03:19:28 +0100 (CET) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mails.dpdk.org (Postfix) with ESMTP id EDA19402AC for ; Thu, 28 Mar 2024 03:19:26 +0100 (CET) Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-29de4c33441so417107a91.1 for ; Wed, 27 Mar 2024 19:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1711592366; x=1712197166; darn=dpdk.org; h=content-transfer-encoding:mime-version:message-id:subject:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=VIDrlzrUBHiucZlwqWRN2qmiMgNv3YP2HYHWaEUftGM=; b=uBEN8An8urDrIHEoxgV/t1zLbOOQ0X+9xV4/jEgcLz6bHJWBcXbxowcqvkzpm4wLeQ mIp4oWxwoPwnRCXZtP68jisn1fL8c3/m3WUGXRRzH2Zwdq8uWEEWPIsc7HAFvOOpoMEh oZIu/kCCZLWamIgrjO+GZDOBf6xtBv5ozmkn3b87qgrrKM3tRQVqd5oWwky0V6DgO1VB Ue1ng5TDPKPwJiMcJOt14aL60/LaZqqPubU10eu64OHBKAMVgoxFG9YeG2n24ipLanfL +XG15ksdZRtGHbGSck9FumfUzbj9IsrQ8InSFjAXSSXR8q2Kh9x8krJG9RJkGPSbRvtZ zo+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711592366; x=1712197166; h=content-transfer-encoding:mime-version:message-id:subject:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VIDrlzrUBHiucZlwqWRN2qmiMgNv3YP2HYHWaEUftGM=; b=qioXnXnRz2pfI3ait6klRDSliLG6ghV9u5oT75A8GIKZQO9EMq1LvhA+oBfmTUAScA ow7Re6mo37yXpRuOOPFx9xuA+tcTKiiwZvm30djZBADkCBdBQGYowC/2EIgGmfdTFCS3 i080JtWFaXVKY6tsP0dgMJZr5JtDhqUEKiiYfyKxJ6iGb7TOiBTjzA74wjW/tVyv0ZH/ s6e7YrnfwoausWaO1cBTwwYGYQxy00oBDrj6S4t6n0ec9Haqeb6Rmbpne+crzS+C2gPL 5fAr919ZhGigzqyQHoEhpSvvRSLN3pn8ruieOvGmPPmC2fm2jfKEdBAQ7Xj8C4DpLmR/ dIzA== X-Gm-Message-State: AOJu0YxdNP8hhKewvm1oIqLwo6IkOOc6cyzlLVeFfvkbKEiAeNeqhb7p e+i4ZkjBc/SBFaiAbSgP4pYugZghvu+MJCGJ9ke+BV9RCac4bvnL9s4FMhOp9nna5Cjnr5Rp9lX P X-Google-Smtp-Source: AGHT+IHK6qwzQroT64yBqFHA1YWieBX2UJxhqbP1MtOD37yoMgfNr8+Ckkfu1BsiY+b2Y1LhFAYhuA== X-Received: by 2002:a17:90a:65c4:b0:29f:ef34:3004 with SMTP id i4-20020a17090a65c400b0029fef343004mr1322873pjs.43.1711592365903; Wed, 27 Mar 2024 19:19:25 -0700 (PDT) Received: from hermes.local (204-195-123-203.wavecable.com. [204.195.123.203]) by smtp.gmail.com with ESMTPSA id er8-20020a17090af6c800b00298cc4c56cdsm2421645pjb.22.2024.03.27.19.19.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 19:19:25 -0700 (PDT) Date: Wed, 27 Mar 2024 19:19:24 -0700 From: Stephen Hemminger To: dev@dpdk.org Subject: Minutes of Technical Board meeting 20-March-2024 Message-ID: <20240327191924.04bdebb5@hermes.local> 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 Members Attending =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Aaron Conole Bruce Richardson Hemant Agrawal Jerin Jacob Kevin Traynor Konstantin Ananyev Maxime Coquelin Morten Br=C3=B8rup Stephen Hemminger (chair) Thomas Monjalon NOTE =3D=3D=3D=3D The technical board meetings are on every second Wednesday at 3 pm UTC. Meetings are public. DPDK community members are welcome to attend on Zoom: https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340? password=3Dd808f1f6-0a28-4165-929e-5a5bcae7efeb Agenda: https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db Minutes of previous meetings: http://core.dpdk.org/techboard/minutes Next meeting will be on Wednesday 3-April-2024 at 3pm UTC, and will be chaired by Thomas. Agenda Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Lcore variables (Mattias) This patch series proposes an alternative for per-lcore variables. Lots of code uses the pattern is per-lcore-data. This solution is simple but uses lots of padding to handle cache lines; and it is easy to overlook some cache patterns and get false sharing. Recent example was hardware will pre-fetch across cache lines. The per-lcore array model also doesn't handle non-EAL threads well. One other issue is that accessing thread local storage variables in another thread works but is undefined according to standards. The proposal defines yet another allocator for per-thread data. It is available early in startup other libraries can use use it. Per-thread allocated storage can safely be used by unregistered threads. Limitations: it does not completely solve the HW pre-fetch issue, and it is not a true heap since there is no free or collection function. Performance is about the same. All implementations have same access pattern. An added benefit is that there is less chance of false sharing bugs. Issues: Valgrind will report leaks. It uses aligned_alloc() and that function is different on Windows. Questions: Should it use hugepages? startup issue before/after memory setup? Or hint the OS? 2. 2024 Events update (Nathan) Planning for North American DPDK summit in Montreal - week of 9 September. Still pending governing board approval. Discussions around an Asia-Pacific event in Bangkok Thailand. This location was suggested as a neutral location (less visa issues). Early stage discussions, still needs more work by governing board. There has been large amount of interest in DPDK webinars in APAC. Are there budget or visa issues with travel for Indian companies? 3. Code Challenge (Ben) Asked Jim Zemlin about cross-project challenges; he agreed good idea but ha= rd to pull off. What next steps are needed to make this event work? Proposal to have DPDK branded merch as part of this. 4. Changes to use markers (Tyler) Using GCC zero sized arrays, used for alignment and reference and prefetch. Not available in MSVC. Existing code has inconsistent usage of markers. Proposed solutions (both maintain ABI): Option 1: anonymous unions in C11, same API. Option 2: break API, use existing cacheline prefetch functions. Existing usage appears to be for prefetch, and hardware rearming. A hybrid approach is to remove markers for the prefetch usage, and use anonymous unions for the hardware rearm. Need a way to prevent introduction of new usage of markers (checkpatch).