Re: prepend mbuf to another mbuf

[Ivan Malov <ivan.malov@arknetworks.am>]

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

Hi Ed,

Tampering with reference counts seems peculiar. Why do that?

I'd recommend you replace the manual prepend workflow that you have described
with just one invocation of 'rte_pktmbuf_chain(mbuf_encap, mbuf_orig)' [1]
or, if it's unfit for whatver reasons, make sure that the manual prepend
code of yours does set correct 'pkt_len' in the new head mbuf and reset
the same field in the original mbuf head. Will that work for you?

Should you have further questions, please don't hesitate to ask.

Thank you.

[1] https://doc.dpdk.org/api-22.11/rte__mbuf_8h_source.html#l01758

On Fri, 26 Jul 2024, Lombardo, Ed wrote:

> 
> 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
> 
> 
>