DPDK CI discussions
 help / color / mirror / Atom feed
* Potential Vlan Filtering Bug - Testpmd
@ 2024-06-07 19:29 Dean Marx
  0 siblings, 0 replies; only message in thread
From: Dean Marx @ 2024-06-07 19:29 UTC (permalink / raw)
  To: aman.deep.singh, yuying.zhang, ferruh.yigit
  Cc: ajit.khaparde, thomas, dev, ci

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

Hello Testpmd and Ethdev maintainers,

I am working at the UNH Community Lab, writing testsuites for DTS.
Currently, I am starting work on a testsuite which will test the vlan
functions in DPDK. It should include testing of:

1. Positive and Negative test of packet vlan filter on an rx_port

2. VLAN stripping

3. VLAN insertion

In attempting to validate the positive and negative test case for part 1, I
am running testpmd, setting an rx_port VLAN 51 tag, and sending packets to
the testpmd port via scapy, with and without the VLAN 51 in the frame
header.

With a Mellanox CX-5, this test case works as expected. The packets with
VLAN tag 51 are accepted on the rx_port and forwarded on, and the ones with
a different vlan tag are dropped.

On the other hand, I have also tested this with an Intel XL710 and Broadcom
57414, and in those cases, I cannot filter based on VLAN tag given my setup
steps. All packets are accepted on the rx_port, even if they have a VLAN
tag not whitelisted on the port; this was found to be the case on DPDK
versions 21.11 and main. Below is the testpmd execution I used for testing:


./dpdk-testpmd -l 2-4 -n 4 -a 0000:61:00.0 -a 0000:61:00.0 -- -i

For reference, here are the runtime configuration commands:

set verbose 1

set fwd mac

set promisc all off

vlan set filter on 0

rx_vlan add 51 0

Using tcpdump, I was able to verify that the VLAN ids were not manipulated
at any point during the forwarding process. ‘Show port stats’ also added
additional verification that this issue was occurring, as the output
indicated that packets were being received on one port and forwarded out
the other on our testbed. Moreover, to eliminate any possible issues
relating to the testbed itself, I also tested VLAN functionality on other
testbeds within our environment, and the issue seems to be consistent
across the board.


Here is the scapy packet I sent:


packet = Ether()/Dot1Q(vlan=51)/Raw(load="xxxxxxx")

For added context, these are the commands that I used to confirm the
offload configuration with output:

show port 0 rx_offload configuration


Port : VLAN_FILTER

Queue[ 0] :

I'm not sure whether this is unintended behavior, or if the application is
working as intended and I'm misunderstanding how to properly setup the vlan
filtering operation on these NICs. Any insight is appreciated, thanks.

[-- Attachment #2: Type: text/html, Size: 10408 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-06-07 19:30 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-07 19:29 Potential Vlan Filtering Bug - Testpmd Dean Marx

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).