From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) by dpdk.org (Postfix) with ESMTP id 4D2E6C31C for ; Thu, 28 May 2015 17:10:35 +0200 (CEST) Received: by igbhj9 with SMTP id hj9so116952222igb.1 for ; Thu, 28 May 2015 08:10:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=np3s3uziXqWoJCgtPsPZgiZvjRoqdcjTantoz/8XYSY=; b=ThMIXBZa8J0sYbBh8zewauF99/hQs6aBKzkHa89Wcrg1T10rFsO3UM8M7uw3JqqPri 5KPtcAKA/wNdppHa1VXEhggvrmMXewB/OE03eVu9/xpZUWzH/EauPr/lGuxIJcrR4uGu XtGlo72yaMLTHyvZzwADfwawj2eEe/q/l7ydsjsW0b3BQKNmheJsHNgfHRR03lab5ZH2 nqCJwFxONRfVInYmTWPhGWe4C9gFauus49QH9WDpX5KR2CLLw0kz/K4fsk/M9Zq0srhT VFVeig6yYUJAUz149wMeI0ryllkGctPQdg8iyoCgcDfwQ6kZc5Fc/L50MRPTEebdcOU4 MNPw== X-Gm-Message-State: ALoCoQlHG2MjrmDDz+mGQMKKCcbhmM1WUM9xm3Aqm5cNb+lOl2pUWXbpXGd6GBppEF5DOYn8Rb0T MIME-Version: 1.0 X-Received: by 10.107.18.222 with SMTP id 91mr3954052ios.34.1432825834647; Thu, 28 May 2015 08:10:34 -0700 (PDT) Received: by 10.36.159.68 with HTTP; Thu, 28 May 2015 08:10:34 -0700 (PDT) In-Reply-To: <20150528075244.469b8557@urahara> References: <57F6A61F-5629-4D11-A78C-397DBB4E8381@inventum.net> <20150528075244.469b8557@urahara> Date: Thu, 28 May 2015 10:10:34 -0500 Message-ID: From: Matt Laswell To: Stephen Hemminger Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 15:10:35 -0000 Since Padam is going to be altering payload, he likely cannot use that API. The rte_pktmbuf_clone() API doesn't make a copy of the payload. Instead, it gives you a second mbuf whose payload pointer points back to the contents of the first (and also increments the reference counter on the first so that it isn't actually freed until all clones are accounted for). This is very fast, which is good. However, since there's only really one buffer full of payload, changes in the original also affect the clone and vice versa. This can have surprising and unpleasant side effects that may not show up until you are under load, which is awesome*. For what it's worth, if you need to be able to modify the copy while leaving the original alone, I don't believe that there's a good solution within DPDK. However, writing your own API to copy rather than clone a packet mbuf isn't difficult. -- Matt Laswell infinite io, inc. laswell@infiniteio.com * Don't ask me how I know how much awesome fun this can be, though I suspect you can guess. On Thu, May 28, 2015 at 9:52 AM, Stephen Hemminger < stephen@networkplumber.org> wrote: > On Thu, 28 May 2015 17:15:42 +0530 > Padam Jeet Singh wrote: > > > Hello, > > > > Is there a function in DPDK to completely clone a pkt_mbuf including the > segments? > > > > I am trying to build a packet mirroring application which sends packet > out through two separate interfaces, but the packet payload needs to be > altered before send. > > > > Thanks, > > Padam > > > > > > Isn't this what you want? > > /** > * Creates a "clone" of the given packet mbuf. > * > * Walks through all segments of the given packet mbuf, and for each of > them: > * - Creates a new packet mbuf from the given pool. > * - Attaches newly created mbuf to the segment. > * Then updates pkt_len and nb_segs of the "clone" packet mbuf to match > values > * from the original packet mbuf. > * > * @param md > * The packet mbuf to be cloned. > * @param mp > * The mempool from which the "clone" mbufs are allocated. > * @return > * - The pointer to the new "clone" mbuf on success. > * - NULL if allocation fails. > */ > static inline struct rte_mbuf *rte_pktmbuf_clone(struct rte_mbuf *md, > struct rte_mempool *mp) >