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 4BA8444185; Fri, 7 Jun 2024 21:30:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 07315402AB; Fri, 7 Jun 2024 21:30:14 +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 8F899402AB for ; Fri, 7 Jun 2024 21:30:12 +0200 (CEST) Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-6c702226b0aso2722485a12.1 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=uDStQM0rY7PduRlTfyVT66sQsreKkdpNOsfj128Ayxa8GHS+/ZCEyJzA+YlAw+zPKZ rlKcW5M3GMU4pnNwGaSJRSi0eY8yyJ9W8Lk5NpI3c1e3c4WDiGwWL8mr5L+5KzfsOdZ/ /g3bzwMF316eu8/ylMpRqSd2xP6Yn1+xYvJHDTbIpYE+Gmf5GqdDl9UHXS5UWknSHKF/ wSffEiN6BQxhX+WtLl9IevupExKlzjqRC54cRBWljMq2yz5dmC4+vblMiLyGORyxpwC1 2P9nfduk2QRsM4l8sNkfprLUxfvE9O/nmsqDkL6HIA1Apyy5E520NinoiZqStAYk3+hT oWTg== X-Forwarded-Encrypted: i=1; AJvYcCWbJPCe9mG/9/cltPlo8IAqOZbQb+9ZkvDvEWLltlyWvLqdRMxzw2GzaQ14pAAQ6VyN/v+A5ka9dpWGaHI= X-Gm-Message-State: AOJu0Yx7gpI2/3NIypECu2UqnRrTC/7v0jfBGevQgDQ9YbDtNUICmdyq 0OWi29PWsLxF1kyvxNyUIhAlCE5UPJqudBBf8B5AX5NRx6YEgGyMSuYeprBQ3By7CIxepz9je1E QQDtD1BJjeLItqncBKBFcW3VNDkTaDQOZ3TsqZg== 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: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-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--