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 38B11A052A; Mon, 25 Jan 2021 16:29:01 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AAE1A140F8C; Mon, 25 Jan 2021 16:29:00 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 421B1140F88 for ; Mon, 25 Jan 2021 16:28:59 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 8D5575805DF; Mon, 25 Jan 2021 10:28:56 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 25 Jan 2021 10:28:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= SkcgfwiO6DLblHPJ64yOiVrTjOeiKbpWG7hQCFy71Gw=; b=T+EsjGEi9OLVO/B4 Z1ZNcykZTZNAp+k4U0UBjNXDzy6uGn6fTEx7mfy9Y/Mv2KTDFk7j+0ioGqdY+w6O u4VP5xI9PJFW5BX9ZqpJAuM1OjTPfhpk/ioXlOVzdCJ38qetFLx2pBSiMYZRYvzE EwIN8GEu5VKxOChQag/r4ZZxCK1cclOZvJusF6r+ST9IZPA2+vDTHFQcvtbh9+En 9J6pqbeRwFoO5gsuaP8I7SHRrab6LVN26SxXdHCh9/ZyqtVktyjn7qBB5JIrRq84 agdqcknXgN89bY/uv070jIwBVL0wv0L9brw3pvMlxQR6/hdEvN0CUZZQoE/SpzQM 4e/A8Q== 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=SkcgfwiO6DLblHPJ64yOiVrTjOeiKbpWG7hQCFy71 Gw=; b=MgNZ/jID8xn7gVVh2ymgWWRqMoFYtYt2KLyuYvx9fG2vpM3CeJmUD/uIS MJFRIbmcj8PWOGJGPLoyI3Tp7GXpzxVLD0pzujqDFSvD97ylPc85ofLgNS1102qP TDHhKjbMJ2eA0zypvifhsjaX9nwZhxgQ5DxvMrdh3iVQZBaQP5+wac4lmzazs5au Z6Q5CGHBslvKQJBJFtyGO7KY3MeCoGBk9TPSovEWsq1xictWipz7CKJbMo4P5Q5d rXi7uq4yZxAzDyEGfwslhkLwSxBnhIWE/5FMhFk//TDzxi3sTelR2+kL8Co6Mhjx ybfqYtAIvoA2UdxduzjkrZG3mOY7A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdevuedt jeevheevteenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 54108240067; Mon, 25 Jan 2021 10:28:53 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob , Honnappa Nagarahalli Cc: Juraj =?utf-8?B?TGlua2XFoQ==?= , "bruce.richardson@intel.com" , Ruifeng Wang , Phil Yang , "vcchunga@amazon.com" , Dharmik Thakkar , "hemant.agrawal@nxp.com" , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , "ferruh.yigit@intel.com" , "aboyer@pensando.io" , "dev@dpdk.org" , "lironh@marvell.com" , "allain.legacy@windriver.com" , nd , Honnappa Nagarahalli , nd Date: Mon, 25 Jan 2021 16:28:49 +0100 Message-ID: <1704692.b6nZu7X71U@thomas> In-Reply-To: References: <1608724059-8562-1-git-send-email-juraj.linkes@pantheon.tech> <2709196.oA3pVeJT1q@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v15 09/12] build: disable drivers in Arm builds 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" 25/01/2021 15:58, Honnappa Nagarahalli: > > 22/01/2021 10:07, Jerin Jacob: > > > On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon > > wrote: > > > > 22/01/2021 09:39, Juraj Linke=C5=A1: > > > > > > > > > disabled drivers, similarly how the command line option > > > > > > > > > works and remove unneeded driver options ported from the > > > > > > > > > old makefile system, since they don't work in the current= Meson > > build system. > > > > > > > > > Add support for removing drivers for cross builds so that > > > > > > > > > we can disable them in cross files. > > > > > > > > > > > > > > > > Why disabling them? > > > > > > > > If a driver is not supported it should disable itseld in it= s meson file. > > > > > > > > > > > > > > > > > > > > > > This is helpful when building for an SoC where we don't want > > > > > > > to build to build a driver, but the build machine actually su= pports > > the driver. > > > > > > > I believe in this case the meson build system would find the > > > > > > > dependencies and designate the driver to be build, but we > > > > > > > don't want to build > > > > > > the driver for that SoC. > > > > > > > > > > > > > > There may be other reasons as well - Honnappa or others from > > > > > > > the Arm community may shed more light on this. > > > > > > IMO, the assumption should be everything compiles on all the > > > > > > platforms. Hence, the disables should be applied to the > > > > > > platforms where the drivers do not compile. > > > > > > > > If a driver does not compile, it can disable itself. > > > > No need for a configuration. > > > > > > > > > Would it be okay to leave the disabled as they're in this commit = and > > leave the updates to the plaform owners? Thomas, what do you think? > > > > > > > > I think this patch should not disable drivers but just add the infr= a to do it. > > > > > > IMO, If the SOC has "fixed" set of dpdk devices, probably better to > > > have positive logic to enable only those in config file. > > > I think, that will be portable and useful. > > > IMO, We can have infrastructure code enable only specific drivers and > > > config owners can later enable the required set. > >=20 > > Yes you're right, enabling makes more sense than disabling for SoCs. > Every SoC also supports PCIe interfaces. This means, one could use them w= ith a PCIe based NIC (we do use these interfaces internally at Arm, I am no= t sure from a deployment perspective). >=20 > If we use the enable logic, the list will be huge? That's also right. The last to talk will be right :)