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 02267A046B for ; Tue, 23 Jul 2019 12:53:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D19B71BFEB; Tue, 23 Jul 2019 12:53:36 +0200 (CEST) Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by dpdk.org (Postfix) with ESMTP id 749B91BFEA for ; Tue, 23 Jul 2019 12:53:35 +0200 (CEST) Received: by mail-oi1-f196.google.com with SMTP id w196so10626262oie.7 for ; Tue, 23 Jul 2019 03:53:35 -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=zoUShst7RmNIVJMDxtqimeoyLF/rtv+PqTpe0wOO77M=; b=Z0TRwWDoofQdlILJ5LQ3Hl5y9GP6jiAWMvzs+GLNn8L3FVTsfsttUS0agUIZbs9y/4 IXv8xrohyo3SfXSY8A39DStVpRjyPV7jsrW6VJIlmHVgKJlgYM9hw/N3K0QVjdJOAQF2 wiyNkE7ey/XArIRpq2WNBDL449AJpygfn6zvw= 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=zoUShst7RmNIVJMDxtqimeoyLF/rtv+PqTpe0wOO77M=; b=oPyVH668lBG7r6OmxX+OkjJGiB5XvO3gS1+1ZYU7teI/Jav0ICXmJQHuI9gwoCxv3W 7YHveuQundV8iLr8RUx6gDqzNKUJQR8FlPvDmk019bmRHRTlTK8ioiTyRfZ5wBBe8xu+ l4GIgYT6VijdagXlxOZyVq2MOHHEsr0TdobbTXHo2IPF9H/vnBlHYyPkpVvulQjxffGN lrNfIHXp2Cc2V57BNBGrt7LB2OME93pGXdy9hFZ2byQ6ogtlzs21yCz8AsQasUp15AS0 NofmK/SaOfG6Yw4f7mpCqgxOmhb14i+nLzf3oeGgBnwG1HzKz8gxMa+FWKUCd9rP3uMf SNsA== X-Gm-Message-State: APjAAAWr7xtJm0wLuDJ9dWOTKgxjP6684lzQpAdH511E/hfvIJ21smgp 2T5HbnNHlto4RQzN3kZJF7W4VlP8lNOrDv2zcM5glA== X-Google-Smtp-Source: APXvYqwyUdv3qdgkdea2QrVKFHMt97d53F/bIsydaBkG5bdIB5667BIVTehCGOiOaaQY0VR5lwDJHd5XGQHtas34SRI= X-Received: by 2002:aca:cc85:: with SMTP id c127mr29503629oig.81.1563879214767; Tue, 23 Jul 2019 03:53:34 -0700 (PDT) MIME-Version: 1.0 References: <20190718033616.37605-1-ajit.khaparde@broadcom.com> <9d27ed67-b177-c9e9-a346-5fab83e5fac2@intel.com> <10243980.JiYW7hy5uA@xps> In-Reply-To: <10243980.JiYW7hy5uA@xps> From: Lance Richardson Date: Tue, 23 Jul 2019 06:53:23 -0400 Message-ID: To: Thomas Monjalon Cc: Ferruh Yigit , Ajit Khaparde , 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" Yes, the platform can be detected at runtime from the PCI device ID. This would be a better approach than adding a configuration parameter, I think. I'll take a look. Thanks, Lance On Tue, Jul 23, 2019 at 4:04 AM Thomas Monjalon wrote: > > 22/07/2019 20:34, Ferruh Yigit: > > On 7/22/2019 6:57 PM, Lance Richardson wrote: > > > 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. > > > > I see this provides a configuration transparent to user, but won't this kill the > > binary portability? If a distro packages an 'armv8a' target and distributes it, > > this won't be usable in your 'stingray' platform for the driver. > > > > But if this is added as a devargs, it can be usable even with distributed > > binaries, by providing proper devargs to binary for a specific platform. And > > documenting this devargs in NIC guide can help users to figure it out. > > > > > 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? > > Can you detect the platform in the PMD? > >