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 BAE0CA0567; Wed, 10 Mar 2021 10:12:55 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 385864068C; Wed, 10 Mar 2021 10:12:55 +0100 (CET) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by mails.dpdk.org (Postfix) with ESMTP id E91C740687 for ; Wed, 10 Mar 2021 10:12:53 +0100 (CET) Received: by mail-io1-f52.google.com with SMTP id 81so17098149iou.11 for ; Wed, 10 Mar 2021 01:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8NNhr7tjIP3LVXdP90eSvgXhasC1l6MJa5LikkO2J20=; b=CBsU3fdEXKMcNaUWzFpfxfwZrM75OH9jkLqKQHKvGbVjdCqT54BvKKkQNrlcy6a5hD YnRxd47QEzEjc9StzyP7Ol9SnxelU0WhTY3RF/x4Zcd2RLoxDAHdzdZm3jIgkPkowudG /HdiiTyFHLGSHzniRXnV4cwKPXEdPXsXZrJKweoE9Q08fVa9IK80ihtiEy9uOJrGWcnA bD55J58zieQzbqQoNV2VQ+7NomB8pHe0eEnZiUlT8/Zsxjv9vOJvWlPIx73rGO9OoZb0 gDV/La4wKu6P+IihP8ZpsHikUrZor1T6BHWIe4I3a+iI9SgaYa9KBuY1fSKwCodncQRh tAZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8NNhr7tjIP3LVXdP90eSvgXhasC1l6MJa5LikkO2J20=; b=fqGR4HmD0E3NZLgFaVrNyQDPQzkRbcCGXpPRW8edZvYq2bbLGqaVyc7cBhvdp4674m EqtIBqGFaimSkmPSScVMiQ29ro3bpDyCVKlHkF6Xz+boWFWbjc/gzdOeOAmmsdYjAVZa UpWzq11vjmC7EqPnFwR+3yT3C7Zd7Y/Ffzc0ijWkWQDOWrIM8XlLCaMyBA7npwF2WQHF ukQC5qolDe0bh2uD9wAzwEt0whmKzZvACwf2zxwRE9D3hqYZKNHuKYmo8HLEFtHpQBm5 8T/oHcZBZu67sj8Qpl5T0DhfKs78yHC1FEBZuA0Kf/AGJv7Jhe04ccXpuWsWJ7CNqXLW 4n5Q== X-Gm-Message-State: AOAM531x7c27hlD2p6K3jvoNNvsGxCSGeys9yT39azG4LJ0ZYQBnLjDa A7/ITMlGEDO210XMCXpMrMbAyxedFWXeMyAHNz8= X-Google-Smtp-Source: ABdhPJwcnyQ6hCXtR4M1DYlM+ueOy5j/8HPJprM+l5xLuwuQwpiLReRGVnQeGelS2SqS2w+hoCXoARocyx2YrCetP0k= X-Received: by 2002:a05:6602:722:: with SMTP id g2mr1677459iox.1.1615367573068; Wed, 10 Mar 2021 01:12:53 -0800 (PST) MIME-Version: 1.0 References: <1610717170-31279-1-git-send-email-juraj.linkes@pantheon.tech> <1612361037-12746-1-git-send-email-juraj.linkes@pantheon.tech> <1612361037-12746-2-git-send-email-juraj.linkes@pantheon.tech> <57b0f0b0b8bb40fda8c87f7eb7ec759b@pantheon.tech> <20210309105654.GA1127@bricha3-MOBL.ger.corp.intel.com> <53b09c78d39e434aad8bfb510efcf994@pantheon.tech> <2f4ec6e353174fa19a36607c3cf7fcc1@pantheon.tech> In-Reply-To: From: Jerin Jacob Date: Wed, 10 Mar 2021 14:42:36 +0530 Message-ID: To: =?UTF-8?Q?Juraj_Linke=C5=A1?= Cc: Honnappa Nagarahalli , Bruce Richardson , Ruifeng Wang , "vcchunga@amazon.com" , Dharmik Thakkar , "hemant.agrawal@nxp.com" , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , "ferruh.yigit@intel.com" , "aboyer@pensando.io" , "lironh@marvell.com" , "dev@dpdk.org" , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v16 1/3] build: disable/enable 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" On Wed, Mar 10, 2021 at 1:12 PM Juraj Linke=C5=A1 wrote: > > > > > -----Original Message----- > > From: Honnappa Nagarahalli > > Sent: Tuesday, March 9, 2021 8:55 PM > > To: Juraj Linke=C5=A1 ; Jerin Jacob > > > > Cc: Bruce Richardson ; Ruifeng Wang > > ; vcchunga@amazon.com; Dharmik Thakkar > > ; hemant.agrawal@nxp.com; Ajit Khaparde > > (ajit.khaparde@broadcom.com) ; > > ferruh.yigit@intel.com; aboyer@pensando.io; lironh@marvell.com; > > dev@dpdk.org; nd ; nd > > Subject: RE: [PATCH v16 1/3] build: disable/enable drivers in Arm build= s > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Mar 09, 2021 at 08:58:39AM +0000, Juraj Linke=C5= =A1 wrote: > > > > > > > > > > Honnappa, Thomas, Bruce, Jerin, you've comments in the = past. > > > > > > > > > > Do you have > > > > > > > > > any further input? > > > > > > > > > > > > > > > > > > > > I think we just need to agree on the allowlist/blocklis= t > > > > > > > > > > mechanism. The current > > > > > > > > > commit allows specifying either an allowlist or a > > > > > > > > > blocklist, but not > > > > > both. > > > > > > > > > However, it would possible to implement specifying both - > > > > > > > > > first we'll allow what's in allowlist and then we'll > > > > > > > > > remove from that set what's > > > > > > > in blocklist. > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > If we have both, I think limiting to only one is by far > > > > > > > > > the sanest > > > option. > > > > > > +1 > > > > > > > > > > > > > > > I'm not fully convinced by the need to have both, since > > > > > > > > > the blocklist allows wildcarding and exception cases. For > > > > > > > > > example "net/[!i]*" will blocklist all net drivers except > > > > > > > > > those starting with an "i". Admittedly, for usability > > > > > > > > > purposes having an allowlist might > > > > > > > work better. > > > > > > > > > > > > > > > > > > > > > > > > > If we only want to build a handful of drivers then the list > > > > > > > > could be very long > > > > > > > (which was the original reason behind having an allowlist), > > > > > > > such as > > > here: > > > > > > > > https://gerrit.fd.io/r/gitweb?p=3Dvpp.git;a=3Dblob;f=3Dbuil= d/exter > > > > > > > > na > > > > > > > > l/ > > > > > > > > pa > > > > > > > > ck ag > > > > > > > > > > > es/dpdk.mk;h=3Dc35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=3DHEAD > > > > > > > > > > > > > > > > An allowlist could also help with maintenance - users won't > > > > > > > > need to add > > > > > > > new drivers to their blocklists (if that's what users need, > > > > > > > like in the case of VPP). > > > > > > > > > > > > > > +1 for allowlist. > > > > > > May be I am missing something here. By creating an allowlist, > > > > > > does it mean drivers are disabled (from compilation) by default= ? > > > > > > For a server platform, where almost all the drivers can be > > > > > > compiled, does the allowlist > > > > > contain all the drivers? > > > > > > > > > > > > > > > > If no allowlist is specified, then everythin will be built - > > > > > nothing will be filtered. > > > > That's confusing. > > > > If a platform like bluefield has an allow list, a new PMD that gets > > > > added will not be compiled for that platform unless someone > > > > explicitly adds > > > it to the allow list. > > > > Is my understanding correct? > > > > > > Yes. > > With this it becomes very easy to skip compiling on a platform. > > > > It wouldn't be mandatory. Maybe I should've said we would be able to choo= se between three behaviors - the current (where everything is built), with = allowlist or with blocklist. > > But maybe the worry is that someone will use the allowlist without fully = understanding the consequences? > > > > > > > > Whereas if the bluefield platform had a block list, then the new PM= D > > > > would be compiled for bluefield platform. > > > > > > > > > > Again, yes. > > > > > > Supporting both would give us the option to choose between the two > > > behaviors. > > > > > > > > > > > > > > If we assume by default everything should compile on Arm > > > > > > platform, but allow for few exceptions (where things are really > > > > > > painful to fix, for > > > > > > ex: compiler needs to be fixed), having a blocklist should be > > > shorter/better? > > > > > > > > > > > > > > > > The blocklist is, I think, agreed upon by everyone. The question > > > > > is whether we want to support the allowlist alongside it and ther= e > > > > > seem to be enough reasons to do that. > > > > Sorry, may be this is answered already, but, what additional benefi= t > > > > does allowlist provide over the blocklist? > > > > > > > > > > VPP could use it: > > > https://gerrit.fd.io/r/gitweb?p=3Dvpp.git;a=3Dblob;f=3Dbuild/external= /packag > > > es/dpdk .mk;h=3Dc35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=3DHEAD > > > > > > They're disabling almost everything so an allowlist would fit there. > > > And they won't need to update the list when a new driver is added > > > (which they won't need). > > This is different from how we started this discussion. The current disc= ussion was > > for DPDK internal use. But the one you are referencing above is for use= rs of > > DPDK. I am fine for providing the allow list for the users of DPDK. But= for DPDK > > internal, I think block list is enough. > > > > That's an interesting suggestion. Jerin, what do you think? Why did you w= ant to have an allowlist? Would this work? # The very reason why VPP chooses to have allow list so that they can control what needs to include. # Another use case is like, in SoCs have fixed internal devices, we can have optimized build for that can have only allow list of the drivers that care about # For server market, block list makes sense # For embedded SoC, allow list makes sense. # Ideal situation is if we support both. # I dont quite understand the above comments for internal use vs external use. If it is exposed as a meson option then I think, it does not matter. Right? > > > > > > > I think it was Jerin who suggested the allowlist. I don't know of an > > > Arm usecase for it, but maybe he has an example. > > > > > > > > > > > > > > By having an allowlist, we will end up with a large part of the > > > > > > code that might not compile on Arm platforms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One final thought, if we add a driver allowlist for cross > > > > > > > > > files, should we also add one as a top-level meson option > > > > > > > > > also for > > > > > consistency? > > > > > > > > > > > > > > > > > > > > > > > > > This definitely makese sense. I was thinking about this and > > > > > > > > wasn't sure > > > > > > > whether I should put it into this commit or a separate one. > > > > > > > The commit evolved a bit and now that it's just an > > > > > > > implementation of an allow/blocklist it makes sense to includ= e > > > > > > > a meson option in it I think > > > > > > > - I'll put it into the next version. > > > > > > > > > > > > > > > > > /Bruce > > > > > > > >