DPDK usage discussions
 help / color / mirror / Atom feed
From: "Sanford, Robert" <rsanford@akamai.com>
To: "Lombardo, Ed" <Ed.Lombardo@netscout.com>,
	"users@dpdk.org" <users@dpdk.org>
Subject: Re: prepend mbuf to another mbuf
Date: Fri, 26 Jul 2024 21:51:52 +0000	[thread overview]
Message-ID: <22E12AE8-06B1-48E2-82B3-FAC0E2FC068E@akamai.com> (raw)
In-Reply-To: <CH3PR01MB8470A9C23BE98292BC45D0BB8FB42@CH3PR01MB8470.prod.exchangelabs.com>

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Did you try to set DEV_TX_OFFLOAD_MULTI_SEGS in txmode.offloads ?

Regards,
Robert


From: "Lombardo, Ed" <Ed.Lombardo@netscout.com>
Date: Friday, July 26, 2024 at 3:30 PM
To: "users@dpdk.org" <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: 4862 bytes --]

  reply	other threads:[~2024-07-26 21:51 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 [this message]
2024-07-29 19:14   ` Lombardo, Ed
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=22E12AE8-06B1-48E2-82B3-FAC0E2FC068E@akamai.com \
    --to=rsanford@akamai.com \
    --cc=Ed.Lombardo@netscout.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).