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 33ACCA0562; Tue, 31 Mar 2020 16:31:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8E24C1BFC1; Tue, 31 Mar 2020 16:31:41 +0200 (CEST) Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by dpdk.org (Postfix) with ESMTP id 80B922C15 for ; Tue, 31 Mar 2020 16:31:40 +0200 (CEST) Received: by mail-ot1-f67.google.com with SMTP id 22so22219996otf.0 for ; Tue, 31 Mar 2020 07:31:40 -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=s4FdMP4pyPzB+2W6myZAdXyMB6ImKj8hrmGETsBdSXI=; b=HJgqkDd4OyGJ1LpqjFfBNYuzkc5egNXaanShrc+1N51CAfv0KUKcNzSsM84J3aX9UU 0cLo1jU8jN8U300b130YRi7kArpKak7KCP0+erTOYtieAOU5kBklxKXsuez9roaKpTEu RuUyulH5wt89UJDvzjYCcuxX+z32EWt5VtUjo= 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=s4FdMP4pyPzB+2W6myZAdXyMB6ImKj8hrmGETsBdSXI=; b=FI2p+3bPTY6RReX7aj3BQu4VHhMDQgY+OePW8VWFA1610hoIkR1A2TJY/QDKD9JeQY FhgScrtGGthmdPo7RkJcSDYKm6X/pK71nMJuVOI4ccyVDr0VSSQUde/9GlnWqANcBck4 WV3ZuQV0BVj1wdLUYHXnYxkicg58mi0I3nVH/te8zCRxkv9h5wlZmJPKbpkLnTLlOOr6 +p3+CFYCm2kirY4fCwJl381UzL20GK3wD1/oyksdgIA/1ZwfLjho7qnz0swWngNoN2Ck bjFmYrv860aiV+lApk8hBfiToIqNzJhX8Zyrr+wwYDATeNNscltOMgq9t4JCaMClMnYC nT5g== X-Gm-Message-State: ANhLgQ1ZtM0RF2Ji/iQS90hCAUbFKsiZmIB/q2ILAnqidILCpA0zKEip j1jw8pCD3d+GWrTH60oNOA9fPGTfuMIQ6itESEGmMw== X-Google-Smtp-Source: ADFU+vvqSbT0Ny0Bv7vVMslC+hfZgdxdR4VMRwZBnDMzP05tPY8Tg80RhYp7zg29HV7scmaX93U/mgoMdF0Nkfj61pA= X-Received: by 2002:a9d:1b31:: with SMTP id l46mr12210668otl.95.1585665099358; Tue, 31 Mar 2020 07:31:39 -0700 (PDT) MIME-Version: 1.0 References: <20200305064500.5634-1-stephen@networkplumber.org> <20200305141809.68d7772b@hermes.lan> In-Reply-To: From: Ajit Khaparde Date: Tue, 31 Mar 2020 07:31:23 -0700 Message-ID: To: Ferruh Yigit Cc: Stephen Hemminger , Lance Richardson , dpdk-dev , dpdk stable , Thomas Monjalon , Bruce Richardson , Andrew Rybchenko Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" On Tue, Mar 31, 2020 at 4:36 AM Ferruh Yigit wrote: > On 3/5/2020 10:18 PM, Stephen Hemminger wrote: > > On Thu, 5 Mar 2020 15:10:48 -0500 > > Lance Richardson wrote: > > > >> Hi Stephen, > >> > >> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger > >> wrote: > >>> > >> > >>> > >>> Make the configuration use the same as other drivers with > >>> vector mode: ixge, i40e, ... > >> s/ixge/ixgbe/? > >> > >>> > >> > >>> This will also make future support of vector mode on other > >>> architectures possible. > >>> > >>> Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode") > >> > >>> +#error "bnxt: IEEE1588 is incompatiable with vector mode" > >>> +#endif > >> s/incompatiable/incompatible/ > >> > >> > >> This was this approach taken in the initial patch set to add bnxt > >> vector mode support, > >> however based on feedback the current approach was used instead. That > discussion > >> can be found here: > >> http://patches.dpdk.org/patch/53683/ > >> > >> If mark support could be treated as a receive offload, it would be > >> possible to choose > >> the non-vector receive handler based on whether mark is enabled. Adding > a kvargs > >> option to disable vector mode might be another possibility. Otherwise, > >> a build-time > >> configuration option does seem to be useful. > >> > >> LGTM... with the above: > >> > >> Acked-by: Lance Richardson > > > > What ever solution must be consistent across all drivers. > > > > 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. May be a dev parameter could be used? That way it would not interfere with the meson builds and also allow a user/application to set vector mode setting as desired.