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 ED88F43095; Fri, 18 Aug 2023 09:07:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E8C1740ED9; Fri, 18 Aug 2023 09:07:29 +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 F146C40395 for ; Fri, 18 Aug 2023 09:07:28 +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-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-613-nkbivatoPdWQxSFOB8CHJQ-1; Fri, 18 Aug 2023 03:07:26 -0400 X-MC-Unique: nkbivatoPdWQxSFOB8CHJQ-1 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-4fe3e3472bcso557195e87.1 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=HXBXvTJvLfMp8dZFtLl86i1hsMdtgW51DD7SdIRSFPaHIQxGdzJrKCqNroSSm0bLVb teki2mIBkjzjcknoVYiuex6D9B9ZJyoRy4N+Xmma9v18ThIdoD2wwfpmtDNl+EoMTP7t SMaTeJvcc2xms2NMyIkUi5tkSFEko8z/5KRz4tb/bMCei+ft9HRlWyTozXiSiOAsjYO/ yqiY1VnTjRCd4KzKUkxUm6FHuH5S3EpDIAtXtu5C1hucQ5kfLWWuUunqlTCZbRxuo/1G hJfV8RiYKDjjGuv2DjqCShaOZF/HW9UTlMyo1LmeOrTddIfH2zDDtFJxfj8YywewdrZn 9tAg== X-Gm-Message-State: AOJu0YxMkJ2QCKleqo3WicUaYhL7JXbrD+QHfiWPT3HiD62LsTJOFQI6 Wqk8Aw//RrTk+vkyc3VQ3XDR48M9mKcyvNaqaDKQX05YKZSbuGc5UnnsNKHm7d9mvprr6ZJcrHw 0Oij6HoToaf4dWqkmoA== X-Received: by 2002:ac2:58f4:0:b0:4fd:b223:92c with SMTP id v20-20020ac258f4000000b004fdb223092cmr800163lfo.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: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-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