From patchwork Thu Sep 29 12:09:01 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Olivier Matz X-Patchwork-Id: 117139 X-Patchwork-Delegate: qi.z.zhang@intel.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 409F6A00C4; Thu, 29 Sep 2022 14:09:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D421D42825; Thu, 29 Sep 2022 14:09:23 +0200 (CEST) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by mails.dpdk.org (Postfix) with ESMTP id 7AD5E41140 for ; Thu, 29 Sep 2022 14:09:21 +0200 (CEST) Received: by mail-wm1-f49.google.com with SMTP id e10-20020a05600c4e4a00b003b4eff4ab2cso3095043wmq.4 for ; Thu, 29 Sep 2022 05:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date; bh=UiWXTLHm7wHLigsDLNT/qflXGby4Na9TSGMdETwa7zY=; b=HnUQCXoM5Xn+j8FLNHJ+8vstzYDL2y8dABjFyLxVCKGtoaQW4qb+4eX6b2AKn03O1q kQrN27C20s9DLSAUqmQOF4sXEcqgvCor4ljbkcufoChYyxnDrU6GMY7SaZK4EuVq5k24 hteEtvvrac3Gx9HMsVv7pUgX1eW9SfIsQNLv2ZXrRiNIRIFobTF9kAl1PPi3IjaIVLma RbbQBazEILyNdjUTVy7NiH04fRXwDD4z1D5xI9ga7g5d6ADczf9DWTxhqmLxD8BK29Ei ViX+A6dDkJqsYVbS6UnBlc49LRC61j1+y0zJDjv0eeiL/ht8Miq6oJk1pcUo6+DJMJQf jJ7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=UiWXTLHm7wHLigsDLNT/qflXGby4Na9TSGMdETwa7zY=; b=yoTUBkhKD+ATVYRgzG6Z1WehKp1eyvlgqWwL056ZH4+0W3bhXTBav7oYIxrnrrusYG ecGzmObgybfkcitQyoio26GBB0M46ftAYO9DjsSsdMQ04FbJlxJ8B8yrk+hNOBdPga5R oRXdU6aotkXL5rbvy+aWmdvCkcqNytL0Ss3uSP/0HMpjQokvFEveHlBiKn89qhucVV23 F9G66yVnEU7qCq7Z5Gj+PLBfJpx6uulloksjL9uLt5OwT8jslldMhWgMGgLSwBtg0B9W lV6DDFB6HWJpvAD2NDgHGSIpjJIzz5bMGQEXAGyL+e9cZt837gsjPlixhVCkVcJUaIv+ /aOg== X-Gm-Message-State: ACrzQf1yLO60baNMMQCQxeUdV+KfiNrvqh8z651H89hFU8ZxxNXR4tgp t0jjcKW1Ahwef1H1QVBqPf9Mu8Av4zDLkAIW X-Google-Smtp-Source: AMsMyM4pASSw3XxzfzFYIoMJ+ivUpO2QPURBwz92my8RKU43qRiP01Sbr8iGV9dCjuDzap4XwJNvVA== X-Received: by 2002:a05:600c:524d:b0:3b4:91ee:933e with SMTP id fc13-20020a05600c524d00b003b491ee933emr2144949wmb.80.1664453361180; Thu, 29 Sep 2022 05:09:21 -0700 (PDT) Received: from gojira.dev.6wind.com ([185.13.181.2]) by smtp.gmail.com with ESMTPSA id n14-20020a5d420e000000b0022cc895cc11sm3798999wrq.104.2022.09.29.05.09.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 05:09:20 -0700 (PDT) From: Olivier Matz To: dev@dpdk.org Cc: Qiming Yang , Wenjun Wu , Qi Zhang , Wei Zhao , stable@dpdk.org Subject: [PATCH 2/2] net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF Date: Thu, 29 Sep 2022 14:09:01 +0200 Message-Id: <20220929120901.639-3-olivier.matz@6wind.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220929120901.639-1-olivier.matz@6wind.com> References: <20220929120901.639-1-olivier.matz@6wind.com> MIME-Version: 1.0 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 When the promiscuous mode is enabled on a VF, the IXGBE_VMOLR_VPE bit (VLAN Promiscuous Enable) is set. This means that the VF will receive packets whose VLAN is not the same as the VLAN of the VF. For instance, in this situation: ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ VF0├────┤VF1 VF2├────┤VF3 │ │ │ │ │ │ │ └────────┘ └────────┘ └────────┘ VM1 VM2 VM3 vf 0: vlan 1000 vf 1: vlan 1000 vf 2: vlan 1001 vf 3: vlan 1001 If we tcpdump on VF3, we see all the packets, even those transmitted on vlan 1000. This behavior prevents to bridge VF1 and VF2 in VM2, because it will create a loop: packets transmitted on VF1 will be received by VF2 and vice-versa, and bridged again through the software bridge. This patch remove the activation of VLAN Promiscuous when a VF enables the promiscuous mode. However, the IXGBE_VMOLR_UPE bit (Unicast Promiscuous) is kept, so that a VF receives all packets that has the same VLAN, whatever the destination MAC address. A similar patch was accepted in Linux kernel (see link). Fixes: 0355c379b71f ("net/ixgbe: support VF promiscuous by PF driver") Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7bb0fb7c63df Signed-off-by: Olivier Matz --- drivers/net/ixgbe/ixgbe_pf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c index c5ef940533..0a0f639e39 100644 --- a/drivers/net/ixgbe/ixgbe_pf.c +++ b/drivers/net/ixgbe/ixgbe_pf.c @@ -771,9 +771,9 @@ ixgbe_set_vf_mc_promisc(struct rte_eth_dev *dev, uint32_t vf, uint32_t *msgbuf) return -1; } - disable = 0; + disable = IXGBE_VMOLR_VPE; enable = IXGBE_VMOLR_BAM | IXGBE_VMOLR_ROMPE | - IXGBE_VMOLR_MPE | IXGBE_VMOLR_UPE | IXGBE_VMOLR_VPE; + IXGBE_VMOLR_MPE | IXGBE_VMOLR_UPE; break; default: return -1;