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 D588543E38; Wed, 10 Apr 2024 18:12:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CF2F0406B7; Wed, 10 Apr 2024 18:12:00 +0200 (CEST) Received: from mail-oa1-f53.google.com (mail-oa1-f53.google.com [209.85.160.53]) by mails.dpdk.org (Postfix) with ESMTP id 43114402EB for ; Wed, 10 Apr 2024 18:11:58 +0200 (CEST) Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-23333dddd8aso238815fac.1 for ; Wed, 10 Apr 2024 09:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1712765517; x=1713370317; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U85Q70PA5LLAo4HPv8YtyxXagnFQlG+YsyLH1FjUFzw=; b=IjugSzfkT1raDWH3y9teK/dgFf6Wgid/500QDRgDg9oNLXRCizH5vRz+o7zTx3KNUe 0zuaQAuq8j/Phj4ivFHD6O5HxsSFP/0Yy4Er6Lvg1U/dcPP6BlaW8eMmxtl12zrHfeez Vuof4x2o+BjHNKV2gjjydu17FFBBolJC55eOU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712765517; x=1713370317; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U85Q70PA5LLAo4HPv8YtyxXagnFQlG+YsyLH1FjUFzw=; b=of9d+MDJdurGpy/MhnMvp5ScEb3DUNA7BmoeNn9KV4hKxEXdayNi3jtJDu5Ol6Ibp6 xRwh41pYrEGZ1Ng8QFfBbWBnees5iiqvf3VsbLk1N6vf+5W+tPmeZS40iubtFgmNPnj0 s+Qmkm25Y1xaz0mpUqyl2GRssLb8VycE/DX2UHMvj0quWMe/pom+duBEwzoZs4ta2C+U iL2PlcDWv4IBi3ciSnSOEIerK97uASLBodcFD2pm7wUvU7FcMtsEV8UCJLSTO2aEQ0FD mnFC04Kojb2LayINdyfXQ1G00qCOZx+54IpLcikk9VAwXzT9JcZyCRMvclN8/T4XPg21 uWiA== X-Gm-Message-State: AOJu0YwFs82u8kgvG0bp6Ssok+uikuyMJdCbN3KbmeBqImNC79GCpVsd N2FgTA+L+noCPcVqs79kjWx64IKFRJID0m4qg6H4RuiIMUjCfu1p+H5DNZGA4+AGkhHTJQzYIP3 9ayv/FrWmNk9LmOI9Gx5jwn+yW40bAWKtAGsC8IeMQWtlPHl3yAU= X-Google-Smtp-Source: AGHT+IF0WaKc9utvR7xJC+Duv+tVqjTH96XKBrtV2ec1BeMmhOUdkOR5PujyLW4ED/SDZpNrbmjuZycJptg9Q0GMMm8= X-Received: by 2002:a05:6870:40c3:b0:22e:cccd:9b7a with SMTP id l3-20020a05687040c300b0022ecccd9b7amr3203825oal.18.1712765516784; Wed, 10 Apr 2024 09:11:56 -0700 (PDT) MIME-Version: 1.0 From: Patrick Robb Date: Wed, 10 Apr 2024 12:11:46 -0400 Message-ID: Subject: DTS WG Meeting Minutes - April 10, 2024 To: dts@dpdk.org Cc: dev , ci@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org ##################################################################### Attendees * Patrick Robb * Jeremy Spewock * Paul Szczepanek * Luca Vizzarro * Juraj Linke=C5=A1 ##################################################################### Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Announcements * AT UNH IOL, Nick installed some Broadcom 25G nics on our DTS dev servers which the team will be able to use for testing their patches going forward. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Patch discussions * Hugepages patch: * Morten noted on the mailing list that 2mb pages may not be supported on all arches, and suggested 32 bit x86 required >4mb * Bruce noted that most distros use PAE mode to allow physical addresses >4gb, and this also means that 32 bit hugepages can be 2mb. Based on this information we are able to proceed without tracking supported hugepage sizes per arch * Juraj notes that PAE allows 32 bit systems to allow for use of more than 4GB of memory. * If we hit problems in the future with the current implementation, it can be refactored at that point to allow for more configurability. * Morten also requested that =E2=80=9Csuggested=E2=80=9D hugepages count= which conf.yaml ships with be kept at 256 * If we want to change it, we need to writeup the specific reasons why. We were originally basing it on the 1024 hugepages example given in DPDK docs system requirements, and then doubling it + buffer since users may run on 2 socket systems in which hugepages are split between numa nodes. * This justification should be in the commit message * Juraj is also going to test increasing his allocation from 256 pages and see if he can run smoke tests successfully (current failing some unit tests) * Various functions need to be renamed to clarify they are hardcoded to set 2mb huge page sizes specifically * Juraj recommends simply setting a class variable for the time being which stores HUGEPAGE_SIZE * We need to document some of the assumptions we are making, like: * If you are setting hugepages from DTS, we assume you are trying to set 2mb pages * This can be set from /doc/guides/tools/dts.rst * Improve output gathering patch: * Current process for gathering output relies on finding expected prompt within output buffer * When the output itself contains the prompt, it is a false positive * So, check for the prompt at the end of the output. * There could still be this prompt at the end of normal output, so it=E2=80=99s not 100% bulletproof, but watching for this should = be easy to maintain * Jeremy will update this patch to make it consistent with other error messages * Testpmd statefullness / params class * Juraj provided some feedback, and Luca will submit another patch later in the month * How do we handle timeouts? Old strategy is setting a timeout per sent command. * The only place where we change the timeout is when we build dpdk * In almost all cases, we do not need to set some custom timeout for sending a command for interactive or noninteractive shells. * Assumption is that when we implement testsuites, new testpmd shell is launched every time we start a new testcase. So, changing the timeout on an instance of the testpmd shell will not affect another testcase. * If for any reason testpmd HAS to be reused for two checks, those two checks need to be within the same testcase. * Should testcases be self contained? * Paul notes that his understanding based on his experience is that testcases should be self contained, and run in any order. * From here we can set a new rule, which is that we need to open and close testpmd every time we start a new testcase * This rule needs to be documented. Just mentioning it in the testpmd class is fine. * The isolation should be enforced by the system, not a requirement placed on developers and requiring human validation * This is essentially forced anyways by having developers use the testpmd context manager * This patch also adding some features which are not used in DTS right now. Usually we don=E2=80=99t want to do this, but these are based on previous discussions and we want to lay the groundwork for further development in the future. The group agrees there is a high likelihood that these features will be required, thus we are comfortable bringing them in now. * https://patchwork.dpdk.org/project/dpdk/list/?series=3D31622 * Skip test cases based on capabilities * Jeremy has rebased his new scatter testcase off of this patch * He will run this * Jeremy is concerned that =E2=80=9Cshow rxq info=E2=80=9D is not giving= correct capability information for scatter on all NICs. * We could compose a list of capabilities which we expect we will need in the near future, and Juraj could add support for those. * How to compose it? We have a rough idea of what testsuites we want to port. We should go through for those testsuites, check for needed capabilties, * Patrick Robbshould make a bugzilla ticket for Nick or Prince checking this * Luca also has an RFC he can submit which adds some support for checking port capability - will need to get on the mailing list and review at a future meeting * Replace XML-RPC server with scapy shell: * Jeremy will submit this soon - needs to CC Juraj for a review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Any other business * None