From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Sune Subject: Re: Packet Cloning Date: Thu, 28 May 2015 18:13:43 +0200 Message-ID: <55673EB7.8020209@bisdn.de> References: <57F6A61F-5629-4D11-A78C-397DBB4E8381@inventum.net> <20150528075244.469b8557@urahara> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: dev@dpdk.org Return-path: Received: from mx.bisdn.de (mx.bisdn.de [185.27.182.31]) by dpdk.org (Postfix) with ESMTP id D114AC34A for ; 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 ; Thu, 28 May 2015 18:13:46 +0200 (CEST) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 >