From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <marc.sune@bisdn.de>
Received: from mx.bisdn.de (mx.bisdn.de [185.27.182.31])
 by dpdk.org (Postfix) with ESMTP id D114AC34A
 for <dev@dpdk.org>; Thu, 28 May 2015 18:13:46 +0200 (CEST)
Received: from [172.16.250.156] (unknown [172.16.250.156])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mx.bisdn.de (Postfix) with ESMTPSA id 80304A3A3B
 for <dev@dpdk.org>; Thu, 28 May 2015 18:13:46 +0200 (CEST)
Message-ID: <55673EB7.8020209@bisdn.de>
Date: Thu, 28 May 2015 18:13:43 +0200
From: Marc Sune <marc.sune@bisdn.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.6.0
MIME-Version: 1.0
To: dev@dpdk.org
References: <57F6A61F-5629-4D11-A78C-397DBB4E8381@inventum.net>
 <20150528075244.469b8557@urahara>
 <CA+GnqAomGjHueNygLmjVWUMc-zGYnK8QrKkv_xhMBCapA-8jLA@mail.gmail.com>
 <CAMFWN9mptDB8o9w1CE5-=S1=VgMYGharMLk2NzFqZ-eH=7ZmKA@mail.gmail.com>
 <CA+GnqArDnYRM+MpngQZhAejLr+0PvmPC2FJE79tSq67g_efw+Q@mail.gmail.com>
In-Reply-To: <CA+GnqArDnYRM+MpngQZhAejLr+0PvmPC2FJE79tSq67g_efw+Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] Packet Cloning
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 16:13:47 -0000



On 28/05/15 18:06, Matt Laswell wrote:
> Hey Kyle,
>
> That's one way you can handle it, though I suspect you'll end up with some
> complexity elsewhere in your code to deal with remembering whether you
> should look at the original data or the copied and modified data.  Another
> way is just to make a copy of the original mbuf, but have your copy API
> stop after it reaches some particular point.  Perhaps just the L2-L4
> headers, perhaps a few hundred bytes into payload, or perhaps something
> else entirely. This all gets very application dependent, of course.  How
> much is "enough" is going to depend heavily on what you're trying to
> accomplish.

mbufs can be chained in multiple segments. So you could first split into 
two segments leaving the big chunk in the original mbuf (chunk2) and 
copy chunk1 into the new mbuf (check prepend, adj and trim).

Marc

[1] http://dpdk.org/doc/api/rte__mbuf_8h.html

>