DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: NAGENDRA BALAGANI <nagendra.balagani@oracle.com>
Cc: Kapil Kumar Jain <kapil.k.jain@oracle.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Olivier Matz <olivier.matz@6wind.com>
Subject: Re: Strange behavior with rte_pktmbuf_clone call
Date: Tue, 3 Jan 2023 11:59:36 +0000	[thread overview]
Message-ID: <50991ce9-1ac6-3bb9-2cf1-efc3e21a60e1@amd.com> (raw)
In-Reply-To: <DM6PR10MB4124C149EA27DBED5923A0F196E99@DM6PR10MB4124.namprd10.prod.outlook.com>

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


      reply	other threads:[~2023-01-03 11:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-23  6:51 NAGENDRA BALAGANI
2023-01-03 11:59 ` Ferruh Yigit [this message]

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=50991ce9-1ac6-3bb9-2cf1-efc3e21a60e1@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=dev@dpdk.org \
    --cc=kapil.k.jain@oracle.com \
    --cc=nagendra.balagani@oracle.com \
    --cc=olivier.matz@6wind.com \
    /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).