From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id E414C5F2F; Thu, 3 Jan 2019 14:47:25 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2019 05:47:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,435,1539673200"; d="scan'208";a="288554652" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga005.jf.intel.com with ESMTP; 03 Jan 2019 05:47:24 -0800 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 3 Jan 2019 05:47:24 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.150]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.46]) with mapi id 14.03.0415.000; Thu, 3 Jan 2019 21:47:22 +0800 From: "Zhang, Qi Z" To: "Zhao1, Wei" , "dev@dpdk.org" CC: "stable@dpdk.org" , "Wu, Jingjing" , "Zhao1, Wei" Thread-Topic: [dpdk-dev] [PATCH] net/ixgbe: fix MAT enable for VF in multicast Thread-Index: AQHUomiUGsg09bGCbEyTsLYOn29gD6WdiuTw Date: Thu, 3 Jan 2019 13:47:21 +0000 Message-ID: <039ED4275CED7440929022BC67E706115331422E@SHSMSX103.ccr.corp.intel.com> References: <1546410760-24879-1-git-send-email-wei.zhao1@intel.com> In-Reply-To: <1546410760-24879-1-git-send-email-wei.zhao1@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzRjYTllZWMtMzQ4Zi00NjlkLTljMTQtODc4YjdhMzVhOGQxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRHBZSEt5YkRDZXVuZENmRDJUUHFleW5PNzN1VDVNNk1EdjVRZGNDeWRXMG9jbUxFRWlwWUZzb1c4N0JGSzdrWCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix MAT enable for VF in multicast 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: , X-List-Received-Date: Thu, 03 Jan 2019 13:47:26 -0000 Hi Wei > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Zhao > Sent: Wednesday, January 2, 2019 2:33 PM > To: dev@dpdk.org > Cc: stable@dpdk.org; Wu, Jingjing ; Zhao1, Wei > > Subject: [dpdk-dev] [PATCH] net/ixgbe: fix MAT enable for VF in multicast What is MAT means ?=20 >=20 > In ixgbe PMD code, all vf ars set with bit IXGBE_VMOLR_ROMPE, which make = vf > accept packets that match the MTA table, if some vf update IXGBE_MTA in > function ixgbe_vf_set_multicast, then all vf will receive packets from th= ese > address. > So thhere is need to set VMOLR register bit ROPE onlty after this vf has = been > set multicast address. If this bit is when pf host doing initialization, = this vf will > receive multicast packets with address written in MTA table. Align to ixg= be pf > kernel 5.3.7 code to fix this bug. There are some typo in you commit log. >=20 > Fixes: 00e30184daa0 ("ixgbe: add PF support") >=20 > Signed-off-by: Wei Zhao > --- > drivers/net/ixgbe/ixgbe_pf.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) >=20 > diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c = index > 4b833ff..0f4b96b 100644 > --- a/drivers/net/ixgbe/ixgbe_pf.c > +++ b/drivers/net/ixgbe/ixgbe_pf.c > @@ -351,7 +351,7 @@ ixgbe_vf_reset_event(struct rte_eth_dev *dev, > uint16_t vf) > int rar_entry =3D hw->mac.num_rar_entries - (vf + 1); > uint32_t vmolr =3D IXGBE_READ_REG(hw, IXGBE_VMOLR(vf)); >=20 > - vmolr |=3D (IXGBE_VMOLR_ROPE | IXGBE_VMOLR_ROMPE | > + vmolr |=3D (IXGBE_VMOLR_ROPE | > IXGBE_VMOLR_BAM | IXGBE_VMOLR_AUPE); > IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr); >=20 > @@ -503,6 +503,7 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev, > uint32_t vf, uint32_t *msgbuf) > const uint32_t IXGBE_MTA_BIT_MASK =3D (0x1 << IXGBE_MTA_BIT_SHIFT) - > 1; > uint32_t reg_val; > int i; > + u32 vmolr =3D IXGBE_READ_REG(hw, IXGBE_VMOLR(vf)); >=20 > /* Disable multicast promiscuous first */ > ixgbe_disable_vf_mc_promisc(dev, vf); > @@ -525,6 +526,9 @@ ixgbe_vf_set_multicast(struct rte_eth_dev *dev, > uint32_t vf, uint32_t *msgbuf) > IXGBE_WRITE_REG(hw, IXGBE_MTA(mta_idx), reg_val); > } >=20 > + vmolr |=3D IXGBE_VMOLR_ROMPE; > + IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr); Please correct me if I'm wrong My understand is MTA table is shared by all VFs (I guess also pf), but what= if two VFs both enable multi-cast but with different address filter? Should we prevent the second one to enable multi-cast if any conflict be de= tected? Otherwise there still will be unexpected behavior. > + > return 0; > } >=20 > -- > 2.7.5