From: "Lombardo, Ed" <Ed.Lombardo@netscout.com>
To: "Sanford, Robert" <rsanford@akamai.com>,
"users@dpdk.org" <users@dpdk.org>
Subject: RE: prepend mbuf to another mbuf
Date: Mon, 29 Jul 2024 19:14:52 +0000 [thread overview]
Message-ID: <CH3PR01MB8470A46C84FD67183346C7048FB72@CH3PR01MB8470.prod.exchangelabs.com> (raw)
In-Reply-To: <22E12AE8-06B1-48E2-82B3-FAC0E2FC068E@akamai.com>
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
Hi Robert,
I tried your suggestion and it resolved my issue for the E810 NIC in PCI PT.
I also tried checking the port txmod.offloads capability and if supported I set txmod.offloads |= RTE_ETH_TX_OFFLOAD_MULTI_SEGS to see if VMXNET3 supported it, and it did.
Why is this required to explicitly set “RTE_ETH_TX_OFFLOAD_MULTI_SEGS “ bit for the Physical NIC but not really required for VMWARE VMXNET3 vNIC?
Thank you!
Regards,
Ed
From: Sanford, Robert <rsanford@akamai.com>
Sent: Friday, July 26, 2024 5:52 PM
To: Lombardo, Ed <Ed.Lombardo@netscout.com>; users@dpdk.org
Subject: Re: prepend mbuf to another mbuf
External Email: This message originated outside of NETSCOUT. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Did you try to set DEV_TX_OFFLOAD_MULTI_SEGS in txmode.offloads ?
Regards,
Robert
From: "Lombardo, Ed" <Ed.Lombardo@netscout.com<mailto:Ed.Lombardo@netscout.com>>
Date: Friday, July 26, 2024 at 3:30 PM
To: "users@dpdk.org<mailto:users@dpdk.org>" <users@dpdk.org<mailto:users@dpdk.org>>
Subject: prepend mbuf to another mbuf
Hi,
I have an issue with retransmitting a received packet with encapsulation headers prepended to original received packet when using E810 NIC for transmit.
I have received a packet and is stored in one or more mbufs. To do encapsulation I am acquiring a mbuf from free pool. The new mbuf is where I add the L2 Header, IPv4 header and GRE header. I update the mbuf with rte_mbuf_refcnt_set(new_mbuf, 1) and rte_mbuf_refcnt_update(mbuf, 1); and then fill in the new mbuf metadata like (nb_segs, pkt_len, port, mbuf->next, etc) from the original mbuf.
When I test this feature in VMWare with VMXNET3 vnic it works perfectly, the packet is transmitted with the encapsulation headers ahead of the original packet seen at the endpoint.
When I test same on Intel E810 only the first mbuf of data is transmitted, the original packet data from remaining mbufs is not transmitted.
I compared the mbufs just prior to transmit, byte by byte, in the VMXNET3 and E810 NIC cases and they are identical, the code path is the same.
I also tried dpdk 17.11 and dpdk 22.11 versions with same results.
Also same test fails with Intel X710 and X540 NICs similar to way E810 fails.
I modified the code to insert the encapsulation headers in the headroom of the original mbuf and it worked perfectly.
What could be the issue with the Intel NICs when transmitting a chain of mbufs, where the first mbuf has only the L2 header, IPv4 header and GRE header and remaining mbuf(s) contain the original packet data?
Thanks,
Ed
[-- Attachment #2: Type: text/html, Size: 7973 bytes --]
next prev parent reply other threads:[~2024-07-29 19:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 19:29 Lombardo, Ed
2024-07-26 21:51 ` Sanford, Robert
2024-07-29 19:14 ` Lombardo, Ed [this message]
2024-07-29 20:20 ` Sanford, Robert
2024-07-27 4:08 ` Ivan Malov
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=CH3PR01MB8470A46C84FD67183346C7048FB72@CH3PR01MB8470.prod.exchangelabs.com \
--to=ed.lombardo@netscout.com \
--cc=rsanford@akamai.com \
--cc=users@dpdk.org \
/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).