From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 20FB744186; Fri, 7 Jun 2024 21:30:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14D8542D6B; Fri, 7 Jun 2024 21:30:15 +0200 (CEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by mails.dpdk.org (Postfix) with ESMTP id 8A14240272 for ; Fri, 7 Jun 2024 21:30:12 +0200 (CEST) Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-681bc7f50d0so2503157a12.0 for ; Fri, 07 Jun 2024 12:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1717788611; x=1718393411; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/FKSojGfz+aixyYYkTOFuzt16laigaq7g6K/gSc4xeo=; b=F1Tv7TDUXmPlByZPb/EQAE3EDsgtnHJkhgY7OsoAl0x9OxfCfBMtYgaRFmU0ye0QoI suNTCABOm+5ESAQHWULsGGI1jHh4W9GFpJc+ih7IPICiNDaMq7+uQfGOfZEYDcHPDGLj cI/cyIaAyifkuut/iH8gKS2Oc9LNzTiUHEGC8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717788611; x=1718393411; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/FKSojGfz+aixyYYkTOFuzt16laigaq7g6K/gSc4xeo=; b=iL/dOiYrewmJURPDTBeB4QLBT757fzZksl/J083gUYambn6X9E6ihT+14xFKayKI/o 5VT2/VClmdQ8jOGSyC5x5QDODXErVWYvM4E9qcv91GxfTaY4IUXKc2XImOW5aPJxkHSw YjjwLIDLVQ8vWGjEw03A5oGd591/trck5rC4NSgr7V/LkDvVO/jfpUsRuDYwiebX7wCt 9oGZxg2pNowjhKe+Ob/X0qS7nhXzkTTaerXvtkDd61gWoQRYrc2lwgki2GyL7IZouCqI Tfx+0+Y4Ks/4yYLkKc0No+aW49xmZIpCGuvmTizN+sXarWUw/nyXRsDezZgIcix44yOE FUNg== X-Forwarded-Encrypted: i=1; AJvYcCUyX5zoyLL3l3UFpsSx1ADQImnm75s1lXr+FaCOQSf6ciZUheLZYfvl0gcLT5i43z1rKMga06WoZkIB4w== X-Gm-Message-State: AOJu0YxKR7F1oE+OWg0FYtRryE4QzmPOq3F7I6AcgzcCW9h5PtbyOss/ u9stmJfYzUIOs3xkAJZu9KcsV1zabvv5Ys25kASy5aH/uR3w0gwibxb972slCp6JrdOdloq67oC /AUoK7SYAzy2fP3vtQj5ocO+PVoJY3XxedpbYCQ== X-Google-Smtp-Source: AGHT+IFQa0k4U9qO6g7HBTqwDjq9MaieyLAFrpfz/n+8JEPgmdTU6Ze9ErR0OmgAKxUDTl1xBP8r7aYQ77iHtT0Fnk4= X-Received: by 2002:a17:903:2304:b0:1f6:a58a:4da with SMTP id d9443c01a7336-1f6b8c4da3dmr98647175ad.3.1717788611387; Fri, 07 Jun 2024 12:30:11 -0700 (PDT) MIME-Version: 1.0 From: Dean Marx Date: Fri, 7 Jun 2024 15:29:05 -0400 Message-ID: Subject: Potential Vlan Filtering Bug - Testpmd 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 Content-Type: multipart/alternative; boundary="000000000000fb3c14061a51d34c" X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org --000000000000fb3c14061a51d34c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. =E2=80=98Show port stats=E2=80= =99 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 =3D Ether()/Dot1Q(vlan=3D51)/Raw(load=3D"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. --000000000000fb3c14061a51d34c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 f= ilter on an rx_port

2. VLAN stripping

3. VLAN insertion<= /p>

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 he= ader.


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 han= d, I have also tested this with an Intel XL710 and Broadcom 57414, and in t= hose cases, I cannot filter based on VLAN tag given my setup steps. All pac= kets are accepted on the rx_port, even if they have a VLAN tag not whitelis= ted on the port; this was found to be the case on DPDK versions 21.11 and m= ain. 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 verb= ose 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. = =E2=80=98Show port stats=E2=80=99 also added additional verification that t= his issue was occurring, as the output indicated that packets were being re= ceived on one port and forwarded out the other on our testbed. Moreover, to= eliminate any possible issues relating to the testbed itself, I also teste= d VLAN functionality on other testbeds within our environment, and the issu= e seems to be consistent across the board.


Here is the scapy packet = I sent:


p= acket =3D Ether()/Dot1Q(vlan=3D51)/Raw(load=3D"xxxxxxx")


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


show port 0 rx_offload co= nfiguration=C2=A0


Port : VLAN_FILTER

=

Queue[ 0] :


I'm not sure whether this is unintended b= ehavior, or if the application is working as intended and I'm misunders= tanding how to properly setup the vlan filtering operation on these NICs. A= ny insight is appreciated, thanks.


--000000000000fb3c14061a51d34c--