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 F069DA0562; Fri, 19 Mar 2021 14:32:26 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 786DC40143; Fri, 19 Mar 2021 14:32:26 +0100 (CET) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by mails.dpdk.org (Postfix) with ESMTP id 659714003F for ; Fri, 19 Mar 2021 14:32:25 +0100 (CET) Received: by mail-il1-f178.google.com with SMTP id c17so8032517ilj.7 for ; Fri, 19 Mar 2021 06:32:25 -0700 (PDT) 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=wUayQPtMUfQuAPMMvRX5KGxvQG4j6skxLV9cMRqkqu0=; b=aO7Fc4T2NSwzmqHS7yJZQIkidnR1x7MhuMnyAQgxuBCYEagpTEy7sWNtu5KaAu/3ZY wr8z6+Du0rL128jSRt56tN73eXqnF+48uuaUJnmbc1ESCoKWYZa4Xv5LPEDAfnX35r1Y /S8J974bwzXZfIJuG/KJKrBRXS9jfmTV6Fd/UngqkBHa47zpRCVZ0ZbEJnClvOsBKSD5 COCMCT2AvFhfL4kkeMRe8MCf8mqahfkmsW9KTsGTUPnX0Uj6lveadpDLN4zs1IJDL4YX nCs5lD9TAcRReQ924Mq9re+bOPYHpG4yQHK2wKj9+lACp0zD2PAdsu+ez/4wqM2J6u9H NQiA== 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=wUayQPtMUfQuAPMMvRX5KGxvQG4j6skxLV9cMRqkqu0=; b=hAEkQZnFSfo/+aw+JMx6RKsin65fvb2YYSYst2jTr1WzzVryzGStN+hG1RvHnJmZ3z FG3qQiuOoMBKSAcfWhMYXvZePn7Jpbzy+u5nLnfjt6UWA37/+z5V9s5wq/3jADrQE6XV FtzFjoMOEB4tTfo9eRvyDlyyGiEAR1DHJM8/S2JfinFS9/6B1UdgKHkl9tr3oTxhnjXZ 8BpomO0yhxi2aWug3Uo3F5iH07PL1meCDkRhmyF2xR0KZ0X41IhVQrREDUTEVd08oi2i XMlPQawzfbGjh4oA1sqVZisc8UlzDfAW5WLAme90Z9vmEyEgc6FvyD43azK92aaPb3o5 HOog== X-Gm-Message-State: AOAM53352nJyhTgFUHGUg4bv+Z4kEOWGe8WrwydCg0x6eDotFuZQMHon Fa5NxlLtKWakzg0opqde4atQbvQdb5TuUfNxw6Q= X-Google-Smtp-Source: ABdhPJxVA9llfcv5Dgh8ENTX9LjVcr/MIUYhErUtfK7LnCl1DqNBwQntKFXiT7yyqJWUOZV+O99bmxbP2OqYw4wzTaQ= X-Received: by 2002:a05:6e02:198e:: with SMTP id g14mr2587589ilf.271.1616160744770; Fri, 19 Mar 2021 06:32:24 -0700 (PDT) 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> <72c3c54c66754753a268b31a68afc38b@pantheon.tech> In-Reply-To: <72c3c54c66754753a268b31a68afc38b@pantheon.tech> From: Jerin Jacob Date: Fri, 19 Mar 2021 19:02:08 +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 Fri, Mar 19, 2021 at 6:51 PM Juraj Linke=C5=A1 wrote: > > > > > > > > > > > > The blocklist is, I think, agreed upon by everyone. The > > > > > > > > > question is whether we want to support the allowlist > > > > > > > > > alongside it and there seem to be enough reasons to do th= at. > > > > > > > > Sorry, may be this is answered already, but, what additiona= l > > > > > > > > benefit does allowlist provide over the blocklist? > > > > > > > > > > > > > > > > > > > > > > VPP could use it: > > > > > > > https://gerrit.fd.io/r/gitweb?p=3Dvpp.git;a=3Dblob;f=3Dbuild/= externa > > > > > > > l/pa > > > > > > > ckag 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 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 block list is > > > > enough. > > > > > > > > > > > > > > > > That's an interesting suggestion. Jerin, what do you think? Why > > > > > did you > > > > 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 care about # For server market, block list makes sense > > > > # For embedded SoC, allow list makes sense. > > > For the embedded SoC, IMO, the upstream project could allow the compi= lation > > for wider set of PMDs/libs. May be the end customer can use the allow l= ist to > > compile/use what is required? > > > > Just to understand, how end customer can enable allow list, if DPDK bui= ld system > > does not support it? > > Also to understand, If we are supporting blocklist, why not have allowl= ist (I > > mean, both of them) as both are required as it caters different use cas= e as > > mention above. We can not emulate allowlist with blocklist as each vers= ion of > > DPDK will have new libraries and PMD's which end user has no clue. Righ= t? > > > I think, that is the reason why VPP is doing the allow list. > > I'm not sure what you mean by this, but to clarify, VPP likely would be u= sing the allowlist in this fashion, but that is not an arm specific usecase= . I think what Honnappa wanted to see was how the allowlist could be used i= n an arm usecase (such as using it in an SoC configuration). There is nothing arm-specific here. Right? allowlist will be common and will be used by all architecture. Right? > >