Message ID | 20210604141601.275430-1-kda@semihalf.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A7730A0A0F; Fri, 4 Jun 2021 16:16:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 284E24068F; Fri, 4 Jun 2021 16:16:30 +0200 (CEST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by mails.dpdk.org (Postfix) with ESMTP id 2BFB740147 for <dev@dpdk.org>; Fri, 4 Jun 2021 16:16:28 +0200 (CEST) Received: by mail-lj1-f178.google.com with SMTP id u22so11746367ljh.7 for <dev@dpdk.org>; Fri, 04 Jun 2021 07:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=gH6FKdV0YvvN5UZii5WTGjTWbkUeRFsW2PELA+O/Jbs=; b=KfSnbE9AsGn5ch+dA9Ja/rcRq17gpbmszhtxR3rwHnSQRiLLXov0xx9HyiN8uBD0jY Nh2jEAYsW1z+Gv5WHuiyTMOHWv8NvcPSmfifVjEWP/TS/C1u6BhS2yGD/8cU16cii77e /AFbtbNT3vNbJfoqLAAHwWDvPsrCLswk7sOHMLBUXYDQkuXzELSm9mt4vw1KJ14QXmgh nvVOe2DpUE3uFc1kzRlnS++UaylVnkGv3q574EvAvz/EvWTlGYSav0St8602jeMZuaJX iw9jAJzIlBMy5MNV/adMeOybon/3JDUzdQj+62ere6BZi8FtNM852x7y9UgNZ2qIc9Ym k1Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=gH6FKdV0YvvN5UZii5WTGjTWbkUeRFsW2PELA+O/Jbs=; b=EHw7qkyn+CJAeEmreHt5reM8on3tInakPQFmd75XuQalPt7z9iujRboqtsPvOkvHxw ZutZ3B4bsNYrwLBFh4FVuCI6S3v0nmVV6sjVrP4s7AaskpkwUjmY5RcnImh4hD5O+Tmz yoOf7kEtz6YLcukyUCO2Fg1iT9g2/W6uoiLlNM2ADpVNZWx7Xp75cli91/nUN6o4TLDP aTSRmV5sLZ8RaSMoqM8Azm60vlaE2S2hFfWvM9fdqJD2jT748ELU1+Id8/NBFHGGqgcl l8P3y63skbMOoLyaesVjnmU4rbSCb8EgcdhG95UOMMHmehCQ/gYs9hS9d4yZNBKnqyh9 oziQ== X-Gm-Message-State: AOAM530jTODT0WbeXAxCMIjeSKHIw+afBkUKQ1ehq14jrUU/VcvssF9U 5nxuSd1T93ZiFPqqAgGBwCY2cw== X-Google-Smtp-Source: ABdhPJxCnh2q0NHqqYniFlxaseNPx5UvQdwA/AOsJD07TxxLMKwjq9M517E3/8vNKWaLCIX5+dIcHA== X-Received: by 2002:a2e:b161:: with SMTP id a1mr3602275ljm.426.1622816187617; Fri, 04 Jun 2021 07:16:27 -0700 (PDT) Received: from localhost.localdomain (89-73-146-138.dynamic.chello.pl. [89.73.146.138]) by smtp.gmail.com with ESMTPSA id h13sm706377lji.101.2021.06.04.07.16.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 07:16:27 -0700 (PDT) From: Stanislaw Kardach <kda@semihalf.com> To: Anatoly Burakov <anatoly.burakov@intel.com> Cc: dev@dpdk.org, Stanislaw Kardach <kda@semihalf.com> Date: Fri, 4 Jun 2021 16:15:58 +0200 Message-Id: <20210604141601.275430-1-kda@semihalf.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v2 0/3] Increase test compatibility with PA IOVA X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
Increase test compatibility with PA IOVA
|
|
Message
Stanislaw Kardach
June 4, 2021, 2:15 p.m. UTC
While working on a RISC-V port, using a HiFive Unmatched (FU740) which does not have IOMMU (hence only RTE_IOVA_PA is available), I've noticed that some of the EAL tests are failing because of a totally different reason than the test itself. Namely the --no-huge flag and --iova-mode=pa can't be used together and EAL init fails warning about a lack of access to physical addresses. This patchset tries to cleanup the --no-huge usage so that it doesn't hide the real state of tests when RTE_IOVA_PA is used (i.e. on platforms without IOMMU). I'm proposing to skip the no-huge test for RTE_IOVA_PA environments as it is not supported by design as well as removing no-huge usage on Linux as it seems that it is used (along with --no-shconf) to increase the compatibility with FreeBSD. Please let me know if I'm missing a bigger picture with the --no-huge and --no-shconf usage on non-FreeBSD platforms. I'm not adding stable@dpdk.org on purpose as this does not affect any current platform I'm aware of (at least in a production scenario). --- V2: - Fix checkpatch errors - Add affected platform in the cover letter. Stanislaw Kardach (3): test: disable no-huge test with PA IOVA test: disable no-huge where it's not necessary test: fix the -n unit test description app/test/test_eal_flags.c | 63 ++++++++++++++++++++++++++------------- 1 file changed, 42 insertions(+), 21 deletions(-)
Comments
On Fri, Jun 04, 2021 at 04:15:58PM +0200, Stanislaw Kardach wrote: > Please let me know if I'm missing a bigger picture with the --no-huge > and --no-shconf usage on non-FreeBSD platforms. > After looking at this issue again I'm abandoning this patchset because it seems wrong for 2 reasons: 1. --iova-mode=pa and --no-huge combination is still unsupported but detecting such situation is not straightforward in the eal_flags_no_huge_autotest. That is because it is not only a product of user input but IOMMU requirements (if any), bus requirements and PA map availability. If a PCI device is bound to UIO and no IOMMU is avilable, then bus requests PA mapping. However if there's no UIO device, PCI reports DC and therefore decision relies on PA map availability. If it's not available, VA will be chosen. This changes between the parent dpdk-test binary being run (available->PA) and the child processes being spawned by the test (not-available->VA). However rte_eal_iova_mode() only reports the final IOVA mode. Even if in the parent process it is PA, it doesn't mean it will be so in the child process. So test will be skipped when it shouldn't. 2. Because of the above, the same test can pass on a non-IOMMU platform if no PCI device is bound to UIO while it would fail if there is a PCI device bound to UIO. It seems that the silent assumption is that fast-tests should be run without any UIO devices (or basically with all buses requestin DC IOVA mode). Sorry for any confusion with this patchset.