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 7542C43080; Wed, 16 Aug 2023 15:16:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 54259410D0; Wed, 16 Aug 2023 15:16:59 +0200 (CEST) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by mails.dpdk.org (Postfix) with ESMTP id C946F40EF0 for ; Wed, 16 Aug 2023 15:16:57 +0200 (CEST) Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-31956020336so3406073f8f.0 for ; Wed, 16 Aug 2023 06:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; t=1692191817; x=1692796617; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=N5oCfZqw8ctSwsq5bJSMbkaNgQ+xIEytmQ8rrZQ3Tcc=; b=NJO0j1cFCyD8Tdk3rjuN52B+Dxp023MVaxXDjMFe7WfDLivIiK2WczqDjwuIHPTDbN 9IRjouugPULZ7bD4cYTE0vOfcQEyEnBF5UIwpFgE2J97XyCPmgbNjgOevP8CW3KsSgpK tFAr4F4F9MEMfNrjjsn70F9KpRu83xsFIOrhaL9kbwqpBVXzRKabWvDRtAXHqv+QUs0r ap7KELkcF0372T5JbD0GxIHNTq5nbejWASzOEpwmY7TEHIN5Hy6ERabbF8IwT801ycAv qP62MHk1niUbSByCMXdKaFbWgI/PVV63rMV8XFhGqU/AQAGvYyI0IklCQyP7CYGjv4h8 R7lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692191817; x=1692796617; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=N5oCfZqw8ctSwsq5bJSMbkaNgQ+xIEytmQ8rrZQ3Tcc=; b=KkFQG49uprQ/bM+HQsDjW8qls4f97TwZwv5J6X/yuVfqkmT9QlBz8SBTCAKXFIALo+ 5/DynnnsEicHUnNXRh1Et5rCHe5U4YBDPObpgdV8pCHOHxH3kFzeLB7xdvKSoMAHQ8Us EntFiyHnsXLIyGOb1oFma1b71oEJ7m8iBQRNbJ+ikHKzstk9yEzdQdsqXcx5LQW3RGp7 zwH9NylWs7v6vnc+oR4HgaZ+ySrZsbIwD9w0xqR5EZ/TK+TuhlMgCS+GzU9t49jqs3Go Ot9YCdtTUDxfprBN/dz+CKd/xhzsneMI/GDGe00FP62MDfGZzZ7+3zOI3l0m8U7oYMd4 084A== X-Gm-Message-State: AOJu0YyAFXj2CW3J5kcmPXnhm4uV5cQ3hKDmKNjoS9Os42wHW5su2M3m Rj/ZqoeMWLb9AXfksS4LkB/o7QD7++a3yqwp2rM= X-Google-Smtp-Source: AGHT+IG23BvpcH5FbtDm2KVxAb1lS2V0BWVJ7KSotEhQGqMXFT3ltd+apDDzOucGF5hC2RNmqqZ4Nw== X-Received: by 2002:adf:fb09:0:b0:316:f9f1:bb0f with SMTP id c9-20020adffb09000000b00316f9f1bb0fmr1316712wrr.34.1692191817386; Wed, 16 Aug 2023 06:16:57 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id l13-20020adfe9cd000000b0031934b035d2sm20588318wrn.52.2023.08.16.06.16.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Aug 2023 06:16:56 -0700 (PDT) Date: Wed, 16 Aug 2023 15:16:56 +0200 From: Olivier Matz To: Bruce Richardson Cc: David Marchand , dev@dpdk.org, ci@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= Subject: Re: [PATCH v5 05/10] app/test: define unit tests suites based on test macros Message-ID: References: <20230721115125.55137-1-bruce.richardson@intel.com> <20230815151053.996469-1-bruce.richardson@intel.com> <20230815151053.996469-6-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Hi, On Wed, Aug 16, 2023 at 01:33:46PM +0100, Bruce Richardson wrote: > On Wed, Aug 16, 2023 at 01:40:41PM +0200, David Marchand wrote: > > On Wed, Aug 16, 2023 at 1:15 PM David Marchand > > wrote: > > > > > > On Wed, Aug 16, 2023 at 1:02 PM Bruce Richardson > > > wrote: > > > > These lines here seem to be exposing a bug in the mempool unit tests for > > > > shared builds, which is why we have a CI failure. > > > > > > > > The mempool unit tests use the mempool "create_empty" API, and then call > > > > the populate APIs to finish setting up the mempool. However, the > > > > create_empty API does not explicitly configure a particular set of mempool > > > > ops for the new mempool, leaving the ops field at 0. This means that unless > > > > the app explicitly sets other ops, the mempool will use the ops from > > > > whatever driver registers itself first. This occurs even when the driver is > > > > unsuitable, e.g. on my Intel system, the dpaa2 is first on the list, > > > > leading to failures in setting up and using the mempool. > > > > > > Hum, it sounds like a bug to me. > > > The dpaa2 driver should not be registered as the default (or here, > > > default platform) mempool. > > > Other mempool drivers ensure that required hw is available, I guess > > > dpaa2 is missing some check. > > > > Ok, re-reading your last comment, I agree it looks like an issue in > > the unit test itself. > > Copying Olivier. > > > No, I think it's not a bug in the test, but rather in the mempool. > Unfortunately, I think the concept of the "default" driver for mempools > seems to exist only when using the mbuf library to create mempools. Even > then, the default mempool is different from what the first entry in the > list is. That's the fundamental issue here, we are using the zero-eth entry > in the ops list, rather than a default one. Yes, Bruce is right. As discussed off-list with David, moving rte_mempool_set_ops_byname() from rte_mempool_create() to rte_mempool_create_empty() would ensure that the ring driver is the default (and taking flags into account).