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 BEA11A0562; Tue, 31 Mar 2020 19:13:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8C2241BFC1; Tue, 31 Mar 2020 19:13:55 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 56BBA2BCE for ; Tue, 31 Mar 2020 19:13:54 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C6CDA5C02FD; Tue, 31 Mar 2020 13:13:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 31 Mar 2020 13:13:53 -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=tGb/aQmAfz6r+v+Vttu5hEhv8HP/uzK0R+ufv5/Km7A=; b=J3QlMtBHb7TP f0HMaofc2ImxNBZC3e7LEyIKe7SD7W0KyXbNfE6A0f5ZJTkMLuum0w70irfc9NXm uLcVeezGME3OHAQdA19dPruTVzyqwXlOANcMrPDBENLDidGUjlX0zo4q9KgksLpm bY4nkJPziW8rzLQ6p8VXusKVjEwrvcM= 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=fm2; bh=tGb/aQmAfz6r+v+Vttu5hEhv8HP/uzK0R+ufv5/Km 7A=; b=1YzHszpLUv7EauTF54izqKueEA1PUuC0JHMhsxektsaR0z0GleI3XpAke cCiZ/4sK5I0xLjVJQlcWmG4syX9801Y09idL0g0uqwdeeLhRVgL+et7dmIFh0I+D JO3Sy1rI1e1sslbWP1kem1a90A1pJ6jaYhq8zXbDmowX41+H2kbxNOS/rXqMcnDm bsh4F6BWsbFL1zMp0Qi2V+QI2j2WRft43xkt/OVVPhaOtbtiDcAj9iHzU1AKVvMS IAMvKKp3xr/uI+sGv3kidWNelDx0VXuiIpoJ7le1nnqA5t5pObLEac42CvB0wJnd bdpJ5mbr2TnyfmfavC7fRu5gBGQHw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 80B7D328005D; Tue, 31 Mar 2020 13:13:52 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger , Ferruh Yigit , Ajit Khaparde Cc: Lance Richardson , dpdk-dev , Bruce Richardson , Andrew Rybchenko Date: Tue, 31 Mar 2020 19:13:50 +0200 Message-ID: <3333271.ZzFAyJQhcr@xps> In-Reply-To: <20200331085830.343dc7e6@hermes.lan> References: <20200305064500.5634-1-stephen@networkplumber.org> <2306774.KokGdZ0ToA@xps> <20200331085830.343dc7e6@hermes.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: allow configuring vector mode 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" 31/03/2020 17:58, Stephen Hemminger: > On Tue, 31 Mar 2020 17:43:55 +0200 > Thomas Monjalon wrote: > > 31/03/2020 16:31, Ajit Khaparde: > > > On Tue, Mar 31, 2020 at 4:36 AM Ferruh Yigit wrote: > > > > I saw Ajit merged this patch to brcm tree, but I am not sure about it. We > > > > have > > > > already removed this compile time option from some PMDs, and driver tries > > > > to > > > > detect to use or not to use vectorization transparently. > > > > > > > > This config is also a problem for the meson, which always sets the flag in > > > > a > > > > hardcoded way. > > > > > > > > But also I am not sure about to need to enable/disable vectorization > > > > explicitly, > > > > this patch seems because of this need. As far as I remember in the past > > > > this > > > > type of runtime configuration rejected to not make driver configuration > > > > more > > > > complex. > > > > > > Since we need a way to disable or enable vector mode. > > > > Why do you need to disable vector optimization? > > Is it for debugging? > > The rte_flow mark operation does not work with the vector optimization. > > The choice to use vector mode is done by the driver earlier in > the initialization process, and then when application programs rte_flow > it has a problem; the flow create would fail. Could we imagine switching the Rx implementation dynamically between 2 bursts?