https://bugs.dpdk.org/show_bug.cgi?id=648
Bug ID: 648
Summary: i40e source pruning causes packets to be dropped
Product: DPDK
Version: 20.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: mgsm...@netgate.com
Target Milestone: ---
Created attachment 146
--> https://bugs.dpdk.org/attachment.cgi?id=146&action=edit
patch
Using DPDK 20.11 with X710 or XL710 NICs, if a VRRP virtual MAC address is
added to a port using rte_eth_dev_mac_addr_add(), advertisements from a higher
priority VRRP peer which are received on that port are dropped by the NIC
before the software gets a chance to see them because the inbound packets
originate from the same source MAC address which was added. This breaks VRRP.
The issue has been reported on DPDK dev mailing list a couple of years ago
(http://mails.dpdk.org/archives/users/2018-May/003128.html), but is still
present.
It also seems to affect linux kernel networking with i40e devices
(https://lore.kernel.org/lkml/20200831103512.00001...@intel.com/), though there
is a workaround available for kernel networking. Running 'ethtool
--set-priv-flags ethX disable-source-pruning on' prevents the packets from
being dropped.
There is no available method that I have found to disable source pruning in the
DPDK i40e driver. Can one be added? Or can the default behavior be changed so
that it is not enabled by default?
Using linux kernel networking, the kernel source code that is called when this
flag is set is here
https://github.com/torvalds/linux/blob/3cb60ee6323968b694208c4cbd56a7176396e931/drivers/net/ethernet/intel/i40e/i40e_main.c#L13548.
Adding a patch to invoke similar logic to my local DPDK build corrected the
problem. My patch just did this unconditionally since there's no flag to
indicate that source pruning should be disabled in the DPDK i40e driver. I will
attach the patch that I used.
The problem was observed in VPP
(https://gerrit.fd.io/r/gitweb?p=vpp.git;a=summary) version 21.01 using the
VRRP plugin. It was reported by multiple users. It affects both X710 and XL710
devices and was observed on both bare metal and using PCI passthrough on
VMware. I reproduced the issue on a VMware VM using PCI passthrough with an
X710 and tested with the attached patch to correct the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
