From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Zhang, Ke1X" <ke1x.zhang@intel.com>,
"Jiang, YuX" <yux.jiang@intel.com>,
"Alvin Zhang" <alvinx.zhang@intel.com>,
"Xing, Beilei" <beilei.xing@intel.com>,
"Guo, Junfeng" <junfeng.guo@intel.com>
Cc: <dev@dpdk.org>, "Zhang, AlvinX" <alvinx.zhang@intel.com>
Subject: RE: [dpdk-dev] [PATCH v3] net/i40e: disable source pruning
Date: Mon, 26 Dec 2022 11:26:42 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D875F4@smartserver.smartshare.dk> (raw)
In-Reply-To: <PH7PR11MB59840C3E93FF6B73D2B9E73EDCEC9@PH7PR11MB5984.namprd11.prod.outlook.com>
+CC Ethernet API maintainers, you might have an opinion about expected default behavior
> From: Zhang, Ke1X [mailto:ke1x.zhang@intel.com]
> Sent: Monday, 26 December 2022 10.04
>
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Monday, February 21, 2022 5:35 PM
> >
> > > From: Jiang, YuX [mailto:yux.jiang@intel.com]
> > > Sent: Monday, 21 February 2022 09.31
> > >
> > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Alvin Zhang
> > > > Sent: Wednesday, October 20, 2021 9:29 AM
> > > >
> > > > VRRP advertisement packets are dropped on i40e PF devices because
> > > when
> > > > a MAC address is added to a device, packets originating from that
> > > > MAC address are dropped.
> > > >
> > > > This patch adds a devarg to support disabling source pruning to
> work
> > > around
> > > > above issue.
> > > >
> > > > Bugzilla ID: 648
> > > >
> > > > Signed-off-by: Alvin Zhang <alvinx.zhang@intel.com>
> > > > ---
> > > Tested-by: Yu Jiang <YuX.Jiang@intel.com>
> > >
> > > Verified patchset
> > > http://patches.dpdk.org/project/dpdk/patch/20211020012831.8480-1-
> > > alvinx.zhang@intel.com/ on baseline dpdk22.03-rc1:ecc0dd455e
> > > "raw/cnxk_gpio: add option to select subset of GPIOs"
> > > Tested pass on Ethernet Controller XL710 for 40GbE QSFP+ 1583, OS:
> > > Fedora Linux 35/5.14.10-300.fc35.x86_64 Test step as below:
> > > ./dpdk-testpmd -l 1,2 -n 1 -a 18:00.0,disable_source_pruning=1 --
> -i
> > > pkt = Ether(src="00:00:5E:00:01:0A")/IP()/Raw("x"*60)
> > > test steps:
> > > 1). testpmd>set verbose 1
> > > testpmd>start
> > > 2). Send the pkt, the pkt can be received by testpmd 3).
> > > testpmd>mac_addr add 0 00:00:5E:00:01:0A 4). Re-send the pkt, the
> pkt
> > > still can be received by testpmd.
> >
> > If source pruning is not the default behavior of all NICs, it should
> be disabled
> > by default in the i40e NIC too.
> >
> > A NIC shouldn't drop any packets unless it has explicitly been
> configured for it!
> > And a NIC shouldn't treat any packets differently than other NICs do,
> unless
> > the NIC has explicitly been configured so!
> >
> > Furthermore, I would prefer that configurations for explicitly
> dropping
> > certain types of packets is available through runtime APIs, e.g.
> RTE_FLOWS,
> > or dedicated functions like rte_eth_promiscuous_enable/disable().
> This
> > patch doesn't support runtime detection of installed NICs performed
> by the
> > application.
> >
> > I am very surprised by this default behavior of a NIC. Please confirm
> that
> > Source Pruning is at least disabled in Promiscuous mode?
> >
> > -Morten
>
> Thanks for your comments @Morten Brørup
> After testing with other NIC like ice, source pruning is the default
> action, it means it is the same action
> for both ice and i40e when receiving in default.
I meant NICs in general, not just Intel NICs. Is it standard behavior for NICs in general (incl. NVIDIA, Broadcom, etc.) to perform source pruning?
They way I read the bug report, the source pruning behavior is specific to Intel NICs. Applications should not be required to pass specific command line parameters to make one vendor's PMDs behave like the general behavior of PMDs from other vendors.
> In this patch, the default is "not disable", it is same with other
> NICs.
Not other NICs in general, only other Intel NICs.
I acknowledge that this patch is a workaround, and certainly an improvement, but why not provide a fix instead? It could be backported to older DPDK releases.
If you want to stick with this workaround instead of providing a proper fix, please also update the documentation to mention that disable_source_pruning=1 is required.
Please also describe how to disable source pruning at runtime. Some applications detect the installed NICs at runtime, so passing NIC specific parameters to the application at startup is not possible.
-Morten
next prev parent reply other threads:[~2022-12-26 10:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 9:04 [dpdk-dev] [PATCH] " Alvin Zhang
2021-10-19 9:38 ` [dpdk-dev] [PATCH v2] " Alvin Zhang
2021-10-20 1:28 ` [dpdk-dev] [PATCH v3] " Alvin Zhang
2022-02-21 8:30 ` Jiang, YuX
2022-02-21 9:35 ` Morten Brørup
2022-12-26 9:03 ` Zhang, Ke1X
2022-12-26 10:26 ` Morten Brørup [this message]
2022-12-26 10:27 ` Morten Brørup
2023-01-09 2:20 ` [PATCH] " Ke Zhang
2023-01-09 7:40 ` Morten Brørup
2023-01-13 12:50 ` Ferruh Yigit
2023-01-30 8:09 ` [PATCH v2] net/i40e: support enabling/disabling " Ke Zhang
2023-01-30 8:41 ` Morten Brørup
2023-01-30 8:58 ` David Marchand
2023-01-31 3:28 ` Zhang, Ke1X
2023-02-01 11:11 ` Thomas Monjalon
2023-02-07 1:40 ` Zhang, Ke1X
2023-02-07 8:35 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98CBD80474FA8B44BF855DF32C47DC35D875F4@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=alvinx.zhang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=junfeng.guo@intel.com \
--cc=ke1x.zhang@intel.com \
--cc=yux.jiang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).