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 71AE243097; Fri, 18 Aug 2023 09:07:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 10CDD42D12; Fri, 18 Aug 2023 09:07:30 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 3DBA740ED9 for ; Fri, 18 Aug 2023 09:07:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692342448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Gdp0TtUvLm6k6LGGazGIm/J/FFS7FXwEC86fYEVi4AQ=; b=efEOOOev0XZ8gwHJtk61lm7kFbIA362EVpHhYPfP9+sywn104ZPsYzSHbHqkz26SDNbDKV xyvDt0tk2tLOphhqCldaqSvAkInfluxdNM4W2JXMAs5vK/XZ75FpvXO1MTF2TrIzeRkZ0b y+w2pCxekUSRQR8md/ol1xSrGgkrLn4= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-219-UdVTXv6WMxaRBMkI8OVAIA-1; Fri, 18 Aug 2023 03:07:26 -0400 X-MC-Unique: UdVTXv6WMxaRBMkI8OVAIA-1 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-4fe32caefd8so549912e87.3 for ; Fri, 18 Aug 2023 00:07:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692342445; x=1692947245; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Gdp0TtUvLm6k6LGGazGIm/J/FFS7FXwEC86fYEVi4AQ=; b=eSfE2ll2wvzfeoWFVqk3/TnfigC1i5IEb/88HHcQFaFPJ2ScI5yjVCoFbcPpNx/tI4 uZTUicUa8YLwpcDoUEMbm2zb+PAzmx1jAjcR91AOLvpqOe2cEPBcJkiCSks+JJxK4hEU 015JuY4RHY1Wgkn/EYCUR0WH50eafIDZS972YtViIDumTkVdDKDMiOYaYzKHdLzwQhdR YdqdmKjAmD/ObeFiTWKQjkkwGhw8+Xn0iDAUWz6bPpQGDy7WcA0oPGk5F6D7Ihd4maCt gszDIqK8ksUwmEhenS9RKcn5I8+4rnHVbiit0d5BuGEi3sdaHN8o0hwIpCvsjDO3pT8/ 5/5w== X-Gm-Message-State: AOJu0Yx6DYAt0obXnU5GQsz9vpYk44HDHeIjh2/C5/LNQ9GHBIwDCNg9 XDNYqEMxIUAPg/Otd9M3glJIAk7CE8R6MjcCprdCtnL+gg7JkMK/SvIvzMtt+YSmkqkNP4CttXW e6Msp6qcjSum1tXi74L4= X-Received: by 2002:ac2:58f4:0:b0:4fd:b223:92c with SMTP id v20-20020ac258f4000000b004fdb223092cmr800168lfo.60.1692342445125; Fri, 18 Aug 2023 00:07:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGQBt4EE9hHUWGABuxzS+PEtzM4YWVuTTYMIgM4NcAMsVacbIw9TFiyPR4Cm4BsBQ04Z4rmaOCBBRwV7/PuKm0= X-Received: by 2002:ac2:58f4:0:b0:4fd:b223:92c with SMTP id v20-20020ac258f4000000b004fdb223092cmr800143lfo.60.1692342444748; Fri, 18 Aug 2023 00:07:24 -0700 (PDT) MIME-Version: 1.0 References: <20230721115125.55137-1-bruce.richardson@intel.com> <20230815151053.996469-1-bruce.richardson@intel.com> <20230815151053.996469-5-bruce.richardson@intel.com> In-Reply-To: From: David Marchand Date: Fri, 18 Aug 2023 09:07:13 +0200 Message-ID: Subject: Re: [PATCH v5 04/10] app/test: build using per-file dependency matrix To: Patrick Robb Cc: Bruce Richardson , dev@dpdk.org, ci@dpdk.org, =?UTF-8?Q?Morten_Br=C3=B8rup?= , Honnappa Nagarahalli , "Ruifeng Wang (Arm Technology China)" , Thomas Monjalon , Aaron Conole , Ferruh Yigit X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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, Aug 16, 2023 at 9:26=E2=80=AFPM David Marchand wrote: > > On Wed, Aug 16, 2023 at 8:30=E2=80=AFPM Patrick Robb = wrote: > > On Wed, Aug 16, 2023 at 10:40=E2=80=AFAM David Marchand wrote: > >> > >> Patrick, Bruce, > >> > >> If it was reported, I either missed it or forgot about it, sorry. > >> Can you (re)share the context? > >> > >> > >> > > >> > Does the test suite pass if the mlx5 driver is disabled in the build= ? That > >> > could confirm or refute the suspicion of where the issue is, and als= o > >> > provide a temporary workaround while this set is merged (possibly in= cluding > >> > support for disabling specific tests, as I suggested in my other ema= il). > >> > >> Or disabling the driver as Bruce proposes. > > > > Okay, we ran the test with the mlx5 driver disabled, and it still fail= s. So, this might be more of an ARM architecture issue. Ruifeng, are you st= ill seeing this on your test bed? > > > > @David you didn't miss anything, we had a unicast with ARM when setting= up the new arm container runners for unit testing a few months back. Ruife= ng also noticed the same issue and speculated about mlx5 memory leaks. He r= aised the possibility of disabling the mlx5 driver too, but that option isn= 't great since we want to have a uniform build process (as much as possible= ) for our unit testing. Anyways, now we know that that isn't relevant. I'll= forward the thread to you in any case - let me know if you have any ideas. > > The mention of "memtest1" in the mails rings a bell. > I will need more detailed logs, or ideally an env where it is reproduced. It is a "recurring" yet not so well known issue. This unit test fails if any part of the DPDK did not release all (hugepage backed) memory and associated hugepages before exiting. In your case here, there is a virtio-net device that the container tries to get its hands on because DPDK scans and probes all available resources by default (and fails to, in this case, but that's not important). Triggering this virtio-net probing makes ethdev allocate its shared memzone for port data, but nothing in ethdev releases the memzone when exiting. Fixing this could be tricky... as the current ethdev code is really vague around which locks protect what (if anything..). I think we hit this issue in the past, and avoided it by running the tests with dynamically linked DPDK binaries (and by doing this, avoid the net drivers get loaded). I can see that you are running the unit tests with a static binary in the report you sent. I think the default is shared mode, so I wonder what could be the reason why UNH builds with static here. In any case, could you have a try and switch to -Ddefault_library=3Dshared (or remove forcing to static mode)? --=20 David Marchand