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 E207BA046B for ; Tue, 23 Jul 2019 10:04:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 719291BFB8; Tue, 23 Jul 2019 10:04:25 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id D17C71BFAD for ; Tue, 23 Jul 2019 10:04:24 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 959A85B1; Tue, 23 Jul 2019 04:04:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 23 Jul 2019 04:04:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=hzf2FEiQ+LRLinoK8+hRMqSO1juChkkc2+mCT7SlkIs=; b=OMBat7A4J6SQ eAG9xGLnfbEigNYln1oXLEI0vsvUYatfJ+H5EuQT9CxyYDrMlG1p8D5Uz04B3iA5 vWzyeaTqDayxFm3Et/S9RaSj9TLcBG40n5bBu1Q0dZA0mx4N0YSAbNmV4vVYyydF TNR+wUFCJ+UxU8SaoH1Ie14kGxytAOM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=hzf2FEiQ+LRLinoK8+hRMqSO1juChkkc2+mCT7Slk Is=; b=ndTw6oPgBAk/yXs50j4NOCRBbge91JbhvxAxVEMwOAf7y3a/+Rt2Wly0n BFx1Lz4YRmg5SoyCUeglMdzOqA6rap7VvEXRaz3fzeENCKpoQCgyUhv3KhT5Ky94 rpRhfsaQD+i8QrsNj71oR6mSTpjLhNDwVREmdtwmlGGLtTevtuTulXT7o36O01Uo SxcG4wMtKpNGtC7OwnbBaex5bQDUk5EGHp1Dag0rjU4eLoAwtzD/z6wLMzU7Wzit jssIwIgIg1VQfUwfkvC0+P6w8PIoz1TzpxTDCz3UK6qY3bKk44gQs6KkLTyyh8VM me/P8kDFj69zvdyVzTVovMz0RCCdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrjeejgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BD87C380084; Tue, 23 Jul 2019 04:04:21 -0400 (EDT) From: Thomas Monjalon To: Lance Richardson Cc: Ferruh Yigit , Ajit Khaparde , dev@dpdk.org, Somnath Kotur Date: Tue, 23 Jul 2019 10:04:20 +0200 Message-ID: <10243980.JiYW7hy5uA@xps> In-Reply-To: <9d27ed67-b177-c9e9-a346-5fab83e5fac2@intel.com> References: <20190718033616.37605-1-ajit.khaparde@broadcom.com> <9d27ed67-b177-c9e9-a346-5fab83e5fac2@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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?