Strange behavior with rte_pktmbuf_clone call

Strange behavior with rte_pktmbuf_clone call

[NAGENDRA BALAGANI]

[-- Attachment #1.1: Type: text/plain, Size: 1796 bytes --]

Hi,

I am seeing strange behavior where rte_pktmbuf_clone is not giving desired result.
Here is the detailed info, in my dpdk application  , once I received the packet info in mbuf, I need to send the same packet to two destinations, the sequence  I should follow is,

(i)                  First, Tunnel the packet to one of desired destination, so I created the shallow copy using rte_pktmbuf_clone, had another mbuf for Outer IP Header for IPinIP tunnel and sent to NIC.

(ii)                Second, I need to modify the source and destination ip addresses of the packet and send out.

The issue, I am seeing is the tunneled packet (clone) have modified IP addresses from (ii).

Code flow:

Main()
{
Struct rte_mbuf *org_mbuf; //lets assume this org_mbuf is holding the packet info.

(i)                  Towards First destination.
Build_tunnel_packet(org_mbuf) {

-          Struct rte_mbuf *clone_buffer;
-          Allocate a clone buffer Clone_buffer = rte_pktmbuf_clone(org_mbuf, clone_pool);

-          Constructed IPinIP info in another mbuf and prepended in clone_buffer
-          Call rte_pktmbuf_tx_burst();
}

(ii)                Towards another destination.
Modify_l3_and_route(org_mbuf)
{

-          Modify L3 information of 'org_mbuf'
-          and Call rte_pkt_mbuf_tx_burst();
}

}

[cid:image003.jpg@01D916C9.1A4FB850]

In the above screenshot, the packet 37 should tunneled as it is by adding the outer ip layer(i.e 182.16.146.*), but the inner L3 information also getting changed (which I am modifying in the second step) for some packets.
Using, rte_pktmbuf_copy(), solving the issue, but in expense of extra mbuf.


Please, help me in understanding what is wrong in the case of rte_pktmbuf_clone()?


Regards,
Nagendra


[-- Attachment #1.2: Type: text/html, Size: 15802 bytes --]

[-- Attachment #2: image003.jpg --]
[-- Type: image/jpeg, Size: 163391 bytes --]

Re: Strange behavior with rte_pktmbuf_clone call

[Ferruh Yigit]

On 12/23/2022 6:51 AM, NAGENDRA BALAGANI wrote:
> Hi,
> 
>  
> 
> I am seeing strange behavior where rte_pktmbuf_clone is not giving
> desired result.
> 

Hi Nagendra,

What is the desired result?

'rte_pktmbuf_clone()' creates indirect mbuf [1], which means network
packet is shared between mbufs, so if you update packet data in one
mbuf, other mbuf will observe the change.
Is this the problem you are seeing? If so this is expected and solution
can be to create a full copy as you mentioned.

Cheers,
ferruh


[1]
https://doc.dpdk.org/guides/prog_guide/mbuf_lib.html#direct-and-indirect-buffers

> Here is the detailed info, in my dpdk application  , once I received the
> packet info in mbuf, I need to send the same packet to two destinations,
> the sequence  I should follow is,
> 
> (i)                  First, Tunnel the packet to one of desired
> destination, so I created the shallow copy using rte_pktmbuf_clone, had
> another mbuf for Outer IP Header for IPinIP tunnel and sent to NIC.
> 
> (ii)                Second, I need to modify the source and destination
> ip addresses of the packet and send out.
> 
>  
> 
> The issue, I am seeing is the tunneled packet (clone) have modified IP
> addresses from (ii).
> 
>  
> 
> Code flow:
> 
>  
> 
> Main()
> 
> {
> 
> Struct rte_mbuf *org_mbuf; //lets assume this org_mbuf is holding the
> packet info.
> 
> (i)                  Towards First destination.
> 
> Build_tunnel_packet(org_mbuf) {
> 
>  
> 
> -          Struct rte_mbuf *clone_buffer;
> 
> -          Allocate a clone buffer Clone_buffer *=
> rte_pktmbuf_clone*(org_mbuf, clone_pool);
> 
>  
> 
> -          Constructed IPinIP info in another mbuf and prepended in
> clone_buffer
> 
> -          Call rte_pktmbuf_tx_burst();
> 
> }
> 
> (ii)                Towards another destination.
> 
> Modify_l3_and_route(org_mbuf)
> 
> {
> 
>  
> 
> -          Modify L3 information of ‘org_mbuf’
> 
> -          and Call rte_pkt_mbuf_tx_burst();
> 
> }
> 
>  
> 
> }
> 
>  
> 
>  
> 
> In the above screenshot, the packet 37 should tunneled as it is by
> adding the outer ip layer(i.e 182.16.146.*), but the inner L3
> information also getting changed (which I am modifying in the second
> step) for some packets.
> 
> Using, rte_pktmbuf_copy(), solving the issue, but in expense of extra mbuf.
> 
>  
> 
>  
> 
> Please, help me in understanding what is wrong in the case of
> rte_pktmbuf_clone()?
> 
>  
> 
>  
> 
> Regards,
> Nagendra
> 
>  
>