From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 34119A04FD; Fri, 4 Nov 2022 07:06:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C223642D10; Fri, 4 Nov 2022 07:06:55 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 4D47B42D0E for ; Fri, 4 Nov 2022 07:06:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667542013; x=1699078013; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bTqUoWaTJJN50W98Umaqp3LcDV9fCYm/G1o/ZX7H7ow=; b=a8a2SqHg5veqYk4kTFSccu6QfMCMHizmx/ANeOmR2A5nvhgMo2ruqb7R Yxgrsne00XeoEYbnYF7QTPE5FNnsZeJfGZ2kjo1OPdY0xiNg7UnAODHe4 BYwm0BNFcJcnh6Gx35VCIT92RwyqZGhK5Yp5R3PgF2hQmeAQwyRoPtrSL OfhtMqq85cTzEljqKclR+JJ/w9XJ5zAI04nBoKv+0oWInrkYEG4QlK+be TUKLDbWMUR8MsjASy6EpkRs1eBZONHbA1BYy78eNH4wT3VT+zfFrNCK89 YP97e1ibaxVX++cWy2hywlH368Z8bEXkJ+squSQVSVyfod+RSP6ploekB A==; X-IronPort-AV: E=McAfee;i="6500,9779,10520"; a="311009959" X-IronPort-AV: E=Sophos;i="5.96,136,1665471600"; d="scan'208";a="311009959" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2022 23:06:52 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10520"; a="634975108" X-IronPort-AV: E=Sophos;i="5.96,136,1665471600"; d="scan'208";a="634975108" Received: from unknown (HELO dpdkserver..) ([10.239.252.174]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2022 23:06:50 -0700 From: Yiding Zhou To: dev@dpdk.org Cc: ktraynor@redhat.com, qiming.yang@intel.com, Yiding Zhou Subject: [PATCH v3] net/iavf: revert fix VLAN insertion Date: Fri, 4 Nov 2022 14:10:00 +0800 Message-Id: <20221104061000.1868113-1-yidingx.zhou@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221018102602.217673-1-yidingx.zhou@intel.com> References: <20221018102602.217673-1-yidingx.zhou@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org The vector Tx path does not support VLAN insertion via the L2TAG2 field, but the scalar path supports. The previous commit was to force to select scalar path as soon as kernel driver requests to use L2TAG2. That logic is incorrect. Because other case like VLAN offloading not required but scalar path selected would have a significant performance drop . Therefore the following commit needs to revert. commit 0d58caa7d6d1 ("net/iavf: fix VLAN insertion") After this commit reverted, the user can select scalar path with the parameter '--force-max-simd-bitwidth' if necessary. Fixes: 0d58caa7d6d1 ("net/iavf: fix VLAN insertion") Signed-off-by: Yiding Zhou --- v3: rebase and change commit log --- drivers/net/iavf/iavf_rxtx_vec_common.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/iavf/iavf_rxtx_vec_common.h b/drivers/net/iavf/iavf_rxtx_vec_common.h index 4ab22c6b2b..a59cb2ceee 100644 --- a/drivers/net/iavf/iavf_rxtx_vec_common.h +++ b/drivers/net/iavf/iavf_rxtx_vec_common.h @@ -253,9 +253,6 @@ iavf_tx_vec_queue_default(struct iavf_tx_queue *txq) if (txq->offloads & IAVF_TX_NO_VECTOR_FLAGS) return -1; - if (txq->vlan_flag == IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2) - return -1; - if (txq->offloads & IAVF_TX_VECTOR_OFFLOAD) return IAVF_VECTOR_OFFLOAD_PATH; -- 2.34.1