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 1637FA0C43; Wed, 20 Oct 2021 16:23:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D55744118F; Wed, 20 Oct 2021 16:23:16 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 1511140142 for ; Wed, 20 Oct 2021 16:23:16 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A24FD5C0136; Wed, 20 Oct 2021 10:23:15 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Wed, 20 Oct 2021 10:23:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=u256.net; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=keH4e kBEmRwH+2bIYPUogmRe4tkENbYayx8rnB20Q18=; b=DRL2PIx7S3+dPLY02QZu+ vQXNZBaIdwmNNDfQssvsHjQ8QIwLh2yGeuBPbC42FFRqg/G9aj2/2BAkz/ZZXK/L ITYsqmlctcwkzKwl1VjN2rmET+fCZTRkdyBgC70Mkb1nQAfqBDV6MJlMzOpxxnI3 D/ANBTHBdNcFnJND4B/tQU4xntw9ABWQBXvtZ8TOcF7UzRBN0vwFHCQn3zZdUSZz dDOVTJWhKBiCNB20/ngx+XFPzv1Fzjv37OGYKZVkrRQWjeYc/IAETX6gq8avwPBg qYwyOorPuiyxF7QJJmvOWjrxVrBrnlVCfrPOP5UqzKuLsAiHC8QpMUxZwKdhxwit w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=keH4ekBEmRwH+2bIYPUogmRe4tkENbYayx8rnB20Q 18=; b=T/T6Z2P9/+5XTirrWho00vXPyw/P9OgS+JR5VqePvxHzHl9D23ZJwQZxI V6ZeyY7R34aTuHu7FQdHvID0PVbjK/A7/fb0s6oSBkEbvV0x4dGUqWPX85ptS6Vx 9t9kBwdZIXRQ3eHbiiAsKEn0Wens3yJkwDXjGV8Miwu5h4ze6FGOyhinApLS0CSf K9VQw2rAt+Nw3zLlbeIHXrM45iahL7J5/YBEs1UGff0fu74rR0tkvEkXNENIeYl8 86X5DR7xujA2oy/NgtWM9STURPd+LlRd8aQ7KsoKCSGYcxZMlFn/djNH2GYVzRV1 AWXOHu9UkVfV11RR2zsvMkcED0heA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvgedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpefirgot thgrnhgptfhivhgvthcuoehgrhhivhgvsehuvdehiedrnhgvtheqnecuggftrfgrthhtvg hrnhepvdeffeehueekuefhhffftddvuddtgfdtkedtudelgffhfeejtdeuudeiudefheef necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrih hvvgesuhdvheeirdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 08FA121E006E; Wed, 20 Oct 2021 10:23:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: <7b7e93e7-1eae-405a-a905-b151f16ed731@www.fastmail.com> In-Reply-To: References: <20211005123012.264727-1-xuemingl@nvidia.com> <20211020111230.2441949-1-xuemingl@nvidia.com> <20211020111230.2441949-4-xuemingl@nvidia.com> <4aefeffc-35a9-4f1f-acc3-4d4682587b81@www.fastmail.com> Date: Wed, 20 Oct 2021 16:22:54 +0200 From: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= To: "Xueming(Steven) Li" , "dev@dpdk.org" , "David Marchand" Cc: "Lior Margalit" , "Thomas Monjalon" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v4 3/3] test/devargs: add devargs test cases 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 Sender: "dev" On Wed, Oct 20, 2021, at 15:53, Xueming(Steven) Li wrote: > On Wed, 2021-10-20 at 13:55 +0200, Ga=C3=ABtan Rivet wrote: >> On Wed, Oct 20, 2021, at 13:12, Xueming Li wrote: >> > Initial version to test global devargs syntax. >> >=20 >> > Signed-off-by: Xueming Li >> > --- >> > app/test/meson.build | 5 ++ >> > app/test/test_devargs.c | 184 ++++++++++++++++++++++++++++++++++++= ++++ >> > 2 files changed, 189 insertions(+) >> > create mode 100644 app/test/test_devargs.c >> >=20 >> > diff --git a/app/test/meson.build b/app/test/meson.build >> > index a16374b7a10..c4b0241010d 100644 >> > --- a/app/test/meson.build >> > +++ b/app/test/meson.build >> > @@ -399,6 +399,11 @@ if dpdk_conf.has('RTE_NET_RING') >> > fast_tests +=3D [['latencystats_autotest', true]] >> > fast_tests +=3D [['pdump_autotest', true]] >> > endif >> > +if dpdk_conf.has('RTE_NET_VIRTIO') >> > + test_deps +=3D 'net_virtio' >> > + test_sources +=3D 'test_devargs.c' >> > + fast_tests +=3D [['devargs_autotest', true]] >> > +endif >>=20 >> Hi Steven, >>=20 >> Thanks for adding new use-cases and expanding the expect. >> The dep check for the test can be improved I think. >>=20 >> When the build is shared, not all built drivers will be available, ev= en if part of the meson config. It might generate false negative when ru= nning your test. >>=20 >> Additionally, even if net_virtio is not built, a subset of your test = remains valid. >>=20 >> Finally, net_virtio might not be generic enough as a driver. A simple= r one could be used, such as net_ring maybe. >>=20 >> Instead of checking the dependencies in the meson file, you could det= ect support in preamble >> of the test: >>=20 >> bool pci_bus_avail =3D (rte_bus_find_by_name("pci") !=3D NULL); >> bool vdev_bus_avail =3D (rte_bus_find_by_name("vdev") !=3D NULL); >> bool eth_class_avail =3D [...] >>=20 >> Then during the test case, depending on the expect part of list[i], >> you can skip the case if its deps were not found. In that case, am IN= FO or DEBUG level >> message could be printed to say that the test was skipped. >>=20 > > For vdev supported drivers, currently no API to find it. Macro worked > for me: > > #ifdef RTE_NET_VIRTIO > { "net_virtio_user0,iface=3Dtest,path=3D/dev/vhost- > net,queues=3D1", > 0, 0, 3, "vdev", "net_virtio_user0", NULL }, > { > "net_virtio_user0,iface=3Dtest,path=3D/class/bus/,queues=3D1", > 0, 0, 3, "vdev", "net_virtio_user0", NULL }, > #endif > > PCI, vdev and eth is enabled by default, seems we don't need any flag. > But macros can be used as well to be safe, how do you think? With the macro you will go back to the same issue the meson-based dep ch= eck has: the macro will be set, but it's possible the relevant .so won't be loade= d when executing the test. For Busses and classes, similarly is there a chance that even though the= y are built, they won't be loaded at runtime and make the test result incorrect? What do you think about switching from net_virtio to net_ring instead ot= herwise? It seems a lighter, utility driver that might be present even in minimal= builds. It is used in EAL tests, I think it makes more sense than net_virtio for= unit tests. The virtio-specific path-based parameters are irrelevant there, the actu= al driver probe won't be executed anyway so any parameter looking like a pa= th will test properly. Checkout app/test/test_eal_flags.c for examples of net_ring dummy devarg= s. --=20 Gaetan Rivet