DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dean Marx <dmarx@iol.unh.edu>
To: aman.deep.singh@intel.com, yuying.zhang@intel.com, ferruh.yigit@amd.com
Cc: ajit.khaparde@broadcom.com, thomas@monjalon.net, dev@dpdk.org,
	ci@dpdk.org
Subject: Potential Vlan Filtering Bug - Testpmd
Date: Fri, 7 Jun 2024 15:29:05 -0400	[thread overview]
Message-ID: <CABD7UXNJ1dj+uwqbCu=Fy+9VyVYaodxUnso+fZR4Z-5xG1BWcA@mail.gmail.com> (raw)

[-- 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 --]

                 reply	other threads:[~2024-06-07 19:30 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='CABD7UXNJ1dj+uwqbCu=Fy+9VyVYaodxUnso+fZR4Z-5xG1BWcA@mail.gmail.com' \
    --to=dmarx@iol.unh.edu \
    --cc=ajit.khaparde@broadcom.com \
    --cc=aman.deep.singh@intel.com \
    --cc=ci@dpdk.org \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=thomas@monjalon.net \
    --cc=yuying.zhang@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).