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 0ADEFA056A; Thu, 11 Mar 2021 18:15:16 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B983F406A3; Thu, 11 Mar 2021 18:15:16 +0100 (CET) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) by mails.dpdk.org (Postfix) with ESMTP id CFF904014D for ; Thu, 11 Mar 2021 18:15:14 +0100 (CET) Received: by mail-il1-f174.google.com with SMTP id v14so19569085ilj.11 for ; Thu, 11 Mar 2021 09:15:14 -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=90ay1zL1//F70z3bBFSiWJnipSLBxD6v92Zqh1pnE4c=; b=s50pEn8mkzL7HXIo+sDI7M9h+8GFEuyH0Z+c8flQSytvl3LrCKMIeu/MY0IwAENn3m hU4GItm2Wlg221CXVczwui4nSRlT1Jcq/sSZMdyiVdBwLOHc5m3xAOqkGNJ8KuNnNaLI N9swMnA+tdpXHkI2wUTd4Bt4AOD9k+dKgeDxSt4nnYJyqtv7jT6umZP0wGq+TQDv7wLw Dh5JGayYSZPn5pB5L5q/bqNZaoZ2mArBCvBwfuwc/2jvoTeuaxbjIZz6maKdL0QMsZ4e 4V+tfRCL9MYqWtRdA0JP+sLfVaXa6h7miYWMErspROMS2DyuPxyxicYoLH+XfkFuOV9J WUSw== 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=90ay1zL1//F70z3bBFSiWJnipSLBxD6v92Zqh1pnE4c=; b=QAVVNUkxpTqCvGEFd8CAA74czA2y5y5TIlZkSVyitkzYD/yYshaou5r6Nn9Ugj3TRC tQKDF+U0RoI2etLckjoHv1r3+fEljkeyb+pbJDXKBEvlbxzZENnMr0tQbIiUYxoOv1GS vZpivZMUNLRZ0qjAxdHy+6I0fOpzklFQsfxmfQsnJVBVGhONmUGbKrhGWW+Rrfm1yP4v Z/RiNYAXL9elNYCgXeeXthxxBbyiknsojsgGYVb0DjUxsXIUbOyLbH0uDJFb2UgkSwgo 5XRK3YAs/HtUiFBAS04p/chlWavZwD3D5SSu7sP4DXvlOoHoZBydDTRXv8NPLTOa3E+Z Zrng== X-Gm-Message-State: AOAM531UCZsY5oWrs2s1uVWupcVGLsCK20LkL2JS0YaisLd2agtEN1YC vM787aZjSJZdsPX3Rcz9KBCzQJB2kxSLjNDL3Jk= X-Google-Smtp-Source: ABdhPJyB3XnWCqJQ0nmUL4p8pSzQTuOnITs7paqFdBAnF8ngWxn7bPhNKIVQrXUGQe4G9MT4IcBI9DNnQGzZDGSagCY= X-Received: by 2002:a92:b70c:: with SMTP id k12mr8044996ili.60.1615482914083; Thu, 11 Mar 2021 09:15:14 -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: Thu, 11 Mar 2021 22:44:57 +0530 Message-ID: To: Honnappa Nagarahalli Cc: =?UTF-8?Q?Juraj_Linke=C5=A1?= , 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 Thu, Mar 11, 2021 at 1:06 AM Honnappa Nagarahalli wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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/blocklist 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=3D= build/e > > > > > > > > > > xter > > > > > > > > > > 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 compilat= ion) 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 someon= e > > > > > > 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 > > choose 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 fu= lly > > understanding the consequences? > Yes. > > > > > > > > > > > > > > > Whereas if the bluefield platform had a block list, then the ne= w > > > > > > PMD would be compiled for bluefield platform. > > > > > > > > > > > > > > > > Again, yes. > > > > > > > > > > Supporting both would give us the option to choose between the tw= o > > > > > 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 alongsid= e > > > > > > > it and there seem to be enough reasons to do that. > > > > > > Sorry, may be this is answered already, but, what additional > > > > > > benefit does allowlist provide over the blocklist? > > > > > > > > > > > > > > > > VPP could use it: > > > > > https://gerrit.fd.io/r/gitweb?p=3Dvpp.git;a=3Dblob;f=3Dbuild/exte= rnal/pa > > > > > ckag es/dpdk > > > > > .mk;h=3Dc35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=3DHEAD > > > > > > > > > > They're disabling almost everything so an allowlist would fit the= re. > > > > > 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 > > > > discussion was for DPDK internal use. But the one you are > > > > referencing above is for users of DPDK. I am fine for providing the > > > > allow list for the users of DPDK. But for DPDK internal, I think bl= ock list is > > enough. > > > > > > > > > > That's an interesting suggestion. Jerin, what do you think? Why did y= ou > > want 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 c= are > > about # For server market, block list makes sense # For embedded SoC, a= llow > > list makes sense. > For the embedded SoC, IMO, the upstream project could allow the compilati= on for wider set of PMDs/libs. May be the end customer can use the allow li= st to compile/use what is required? Just to understand, how end customer can enable allow list, if DPDK build system does not support it? Also to understand, If we are supporting blocklist, why not have allowlist (I mean, both of them) as both are required as it caters different use case as mention above. We can not emulate allowlist with blocklist as each version of DPDK will have new libraries and PMD's which end user has no clue. Right? I think, that is the reason why VPP is doing the allow list. > For ex: we use PCIe interfaces with external NICs for the embedded SoCs (= where there is support). > I think the list of PMDs/libs enabled/disabled on a given platform is ano= ther discussion. This should not prevent us from supporting the allowlist. > > > # Ideal situation is if we support both. > > # I dont quite understand the above comments for internal use vs extern= al > > use. If it is exposed as a meson option then I think, it does not matte= r. 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 on= e. > > > > > > > > > The commit evolved a bit and now that it's just an > > > > > > > > > implementation of an allow/blocklist it makes sense to > > > > > > > > > include a meson option in it I think > > > > > > > > > - I'll put it into the next version. > > > > > > > > > > > > > > > > > > > > > /Bruce > > > > > > > > > >