From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 259C2A046B for ; Mon, 22 Jul 2019 19:57:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2403E1BEFF; Mon, 22 Jul 2019 19:57:54 +0200 (CEST) Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by dpdk.org (Postfix) with ESMTP id 4C0CC1BEFD for ; Mon, 22 Jul 2019 19:57:52 +0200 (CEST) Received: by mail-ot1-f68.google.com with SMTP id j19so2703592otq.2 for ; Mon, 22 Jul 2019 10:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YXfcjPHtTNidN1mzOCf7wL1IueqmAj2PDg63k1BD7fc=; b=UzGo6PydMTPZ5xSd62IBIZgy96GwjBOvunDeoxM5rn28TxW8LKGLE839Q+tL0qrHmL A048J8+hlEeEfOx0Mjbkj4LydZ4EzIudet7/2DiM8fbuPKfTdVlwlureJTmNqgwBbgpx yHOmo7nqWJ664UfieQ1+c/UA52/9qqafhQRIo= 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; bh=YXfcjPHtTNidN1mzOCf7wL1IueqmAj2PDg63k1BD7fc=; b=DrOZLXxzZzMFf+FN1J9fOjIkDTlNmPz2qEwgP0o0Ui8x6mmZWMguq3i1dviste9NN0 r/ZZ8hRuHb9t9+mkOKr9i9ArZMgvrw2zJhZJkR1WdUD9213WM4gmTCc3tKFKSn6CHDBF UQB8YJv+M1C568r5UkKfd6f4XgIdnjPvZ3W6diDVgd4PtzmPsVj1Rulaty07t6SI1CqT xjHKBfpIGG0PUB6WOJHNXnd0p994wW9A+gUgGkCaeOOMQwy0MwTUNEWuDrEUsMceISiW IOQf/5snWAFIzRqMUz7ymO/iCd0dbE9bLlUdlYVpLUCMrpOPTjM6/QVln43c5T1NXZRm 7a4w== X-Gm-Message-State: APjAAAXukVNFcGvwbUBisjid0ZcaN2T2o6mX3mZsX5gpi5U9ZmCAH/Tv su1mmXkcH9vN3EOlQ0iLC/5MC9uoPW00WwtGIH09ug== X-Google-Smtp-Source: APXvYqy7VR/uFZVwYG7eIs0rQFYoTQHLbYaMFk9Pw3DUrTnGHIZi3w/I2YbtJezPfAwRBomiHqkFVrtSnvkJoypLuKI= X-Received: by 2002:a9d:6a4d:: with SMTP id h13mr695374otn.259.1563818271804; Mon, 22 Jul 2019 10:57:51 -0700 (PDT) MIME-Version: 1.0 References: <20190718033616.37605-1-ajit.khaparde@broadcom.com> <20190718033616.37605-10-ajit.khaparde@broadcom.com> <3634179.vNFH5eg47m@xps> In-Reply-To: <3634179.vNFH5eg47m@xps> From: Lance Richardson Date: Mon, 22 Jul 2019 13:57:40 -0400 Message-ID: To: Thomas Monjalon Cc: Ajit Khaparde , Ferruh Yigit , dev@dpdk.org, Somnath Kotur Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 09/22] net/bnxt: use dedicated cpr for async events X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Mon, Jul 22, 2019 at 11:06 AM Thomas Monjalon wrote: > > 22/07/2019 16:57, Ferruh Yigit: > > On 7/18/2019 4:36 AM, Ajit Khaparde wrote: > > > From: Lance Richardson > > > --- a/config/common_base > > > +++ b/config/common_base > > > @@ -212,6 +212,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n > > > # Compile burst-oriented Broadcom BNXT PMD driver > > > # > > > CONFIG_RTE_LIBRTE_BNXT_PMD=y > > > +CONFIG_RTE_LIBRTE_BNXT_SHARED_ASYNC_RING=n > > > > Normally we don't want to introduce new config time options as much as possible. > > > > This is what happens when patches slip in the last minute, please Ajit try to > > send patches before proposal next time. > > > > And back to the config option, is it something have to be a compile time flag > > (if so why?), can it be replaced by a devarg? > > I confirm it is nack. > I don't see any reason not to replace it with a runtime devargs. > > This build-time configuration option was introduced because the "shared async completion ring" configuration is needed for one specific platform, arm64-stingray-linux-gcc. This configuration has a number of drawbacks and should be avoided otherwise. Making it a run-time option will add complexity and introduce the possibility that existing stingray users will not know that they need to specify this option as of 19.08, so it would be good if some other way could be found to handle this. Other than perhaps using RTE_ARCH_ARM64 to select the shared completion ring configuration (which would obviously affect all ARM64 users), are there any other options that might be acceptable? It's maybe worthwhile to note that the last several DPDK releases use the "shared completion ring" configuration. Thanks and regards, Lance