On Thu, Nov 27, 2025 at 11:41 AM Jyotsna Dhumale <[email protected]> wrote:
> Hi Jay, > Thanks a lot for your reply and support in understanding and addressing > the issue. > > We are running *VPP + DPDK IAVF*. > Attached the *startup.conf *and *setup.txt* we are using while running > vpp. > Below is the host *VF *details. Let me know incase you need any other > information. > > *0000:01:01.0 *Ethernet controller [0200]: Intel Corporation Ethernet > Adaptive Virtual Function [8086:1889] (rev 02) > Subsystem: Super Micro Computer Inc Device [15d9:0000] > Kernel driver in use: vfio-pci > Kernel modules: iavf > > Thanks and regards, > Jyotsna > > On Wed, Nov 26, 2025 at 8:00 PM Jay Wang via lists.fd.io <jay.wang2= > [email protected]> wrote: > >> Hi Jyotsna, >> >> >> >> Just to confirm --- are you running VPP + DPDK IAVF, or VPP + the AVF >> plugin with the quick workaround? >> >> I’m asking because the patch is only applicable to VPP + DPDK IAVF. >> >> If you are using that setup, could you please share your startup.conf and >> the VPP CLI commands you used to configure VPP? >> >> That will help me look into the issue in more detail. >> >> >> >> Cheers, >> >> Jay Wang >> >> *From:* [email protected] <[email protected]> *On Behalf Of *Jyotsna >> Dhumale via lists.fd.io >> *Sent:* Tuesday, November 25, 2025 10:21 AM >> *To:* [email protected] >> *Cc:* [email protected]; Paul Szczepanek <[email protected]>; >> Vinod Krishna <[email protected]>; Dhruv Tripathi < >> [email protected]>; Wathsala Vithanage <[email protected]> >> *Subject:* Re: [vpp-dev] [VPP 25.02 | ARM64 | E810-C | IAVF] Packets >> showing length 65535 in DPDK input node (works fine on VPP 22.02) >> >> >> >> Hi Jay Wang, >> Thanks a lot for the patch. Even I am facing the same problem[pkt_len >> 65535] with *VPP25.02* and *ARM64* >> >> *Board : Ampere(R) Altra(R) Processor Q64-30 CPU @ 3.0GHz NIC : E810-C 4 >> ports* >> I tested with the patch you provided, but I am still running into same >> problem of pkt_len coming as 65535. >> Attached the build log for your reference, which shows patch is applied >> correctly and build is successful. >> Later VPP is built using the new vpp-ext-dep package generated with the >> patch. >> >> Anything that I am missing or missing in the patch? >> >> Let me know if you need any other information from my side. >> >> Thanks and regards, >> >> Jyotsna >> >> >> >> On Thu, Nov 20, 2025 at 3:15 AM Jay Wang via lists.fd.io <jay.wang2= >> [email protected]> wrote: >> >> Hi Nousi, >> >> >> >> I can confirm that I was able to reproduce your issue in my local test >> environment(*Ampere Altra Max 96 Cores* with *the Intel E810-C 2x ports >> NIC*). >> >> The issue also persists in the latest VPP codebase, so I spent some time >> investigating it. >> >> From what I observed, commit[1] appears to be the root cause. This commit >> introduces NEON intrinsics to add support for the IAVF Rx vector path on >> Arm platforms in DPDK. >> >> I don’t want to bother you with the implementation details of the Rx >> vector function[2]. But in short, the issue occurs because the function >> writes the *pkt_len* field to the wrong location in the *rte_mbuf* when >> copying from the hardware descriptor. >> >> I’ve created a quick workaround for VPP 25.02(see attached patch) and >> tested it with 64B/1024B packets. It seems to work fine. Please give it a >> try and let me know if it resolves the issue on your side. >> >> >> >> VPP 25.02 works fine on X86 systems because it uses a different Rx vector >> code path. >> >> Interestingly, I observed a similar packet length issue when testing the >> X86 counterpart of Rx vector code path[3]. >> >> >> >> Thanks, >> >> Jay Wang >> >> >> >> [1] https://gerrit.fd.io/r/c/vpp/+/37017 >> >> [2] >> https://github.com/DPDK/dpdk/blob/main/drivers/net/intel/iavf/iavf_rxtx_vec_neon.c#L144 >> >> [3] >> https://github.com/DPDK/dpdk/blob/main/drivers/net/intel/iavf/iavf_rxtx_vec_sse.c#L391 >> >> *From:* [email protected] <[email protected]> *On Behalf Of *nousi >> via lists.fd.io >> *Sent:* Tuesday, November 11, 2025 2:22 PM >> *To:* [email protected] >> *Subject:* [vpp-dev] [VPP 25.02 | ARM64 | E810-C | IAVF] Packets showing >> length 65535 in DPDK input node (works fine on VPP 22.02) >> >> >> >> Hi everyone, >> >> I’m seeing a packet length issue after upgrading to *VPP 25.02* on *ARM64 >> (Ampere® Altra® Q64-30 @ 3.0GHz)* with an *Intel E810-C (4x ports)* NIC >> using the *IAVF driver*. >> >> All packets received in the *dpdk-input node* show a *length of 65535 >> bytes*, which is clearly incorrect. This is visible in both *trace* and * >> pcap* captures. >> >> Here’s what I’ve observed so far: >> >> - The issue only appears with *VPP 25.02* on *ARM64*. >> - The *same platform (hardware + NIC)* works perfectly with *VPP >> 22.02* — packet lengths are reported correctly. >> - On *X86 *systems, *VPP 25.02* also works fine (no packet length >> issue). >> - So it seems specific to *VPP 25.02 + ARM64 + IAVF driver* >> combination. >> >> *Setup details:* >> >> - *CPU:* Ampere® Altra® Q64-30 (ARM64) >> - *NIC:* Intel E810-C (4 ports) >> - *Driver:* IAVF (DPDK) >> - *VPP version:* 25.02 >> - *Symptom:* All packets show length = 65535 in dpdk-input node >> >> Has anyone else seen this behavior or is aware of any related changes in * >> VPP 25.02* or the * IAVF/DPDK layer* for ARM64? >> Would appreciate any pointers, patches, or debug hints — especially if >> someone has tested E810/IAVF on ARM with newer VPP versions. >> >> Thanks a lot in advance! >> >> *Nousi.* >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> >> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> >> >> >>
set interface state vpp-intf1/1/0 up set interface reassembly vpp-intf1/1/0 on create host-interface name eth-bh0 set interface state host-eth-bh0 up set interface mtu packet 1500 host-eth-bh0 create bridge-domain 12345 set interface l2 bridge host-eth-bh0 12345 set interface l2 bridge vpp-intf1/1/0 12345 set interface mtu packet 1500 vpp-intf1/1/0 create loopback interface mac d4:ac:bd:b0:fe:02 instance 12345 ip route add 0.0.0.0/0 via 10.200.160.1 loop12345 set interface ip address loop12345 10.200.160.10/24 set interface ip address loop12345 10.200.160.20/24 session enable app ns add id vcl secret 614235 if loop12345 set interface l2 bridge loop12345 12345 bvi set interface mtu packet 1500 loop12345 set interface state loop12345 up
startup.conf
Description: Binary data
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26561): https://lists.fd.io/g/vpp-dev/message/26561 Mute This Topic: https://lists.fd.io/mt/116238372/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
