From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by dpdk.org (Postfix) with ESMTP id C704AC31C for ; Thu, 28 May 2015 17:38:42 +0200 (CEST) Received: by oihd6 with SMTP id d6so35268924oih.2 for ; Thu, 28 May 2015 08:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBNCUTE+/7n60QzcBG0Z++lag9EhtKo/20285tTZE9o=; b=LPqZU9nH7oeRaqzMqEkutZdPAevEgUBNDssFWrPIs67jvfgnXGakZqc2qbLvMf1LtB zw3rcYKNlZI235cgALOuSwK3D2u2ncWuNrW5K3BhL1RhQkHY9LCQoaxeZoqtdKdk9nqu c1R++gROzZM34WMNjlAjW4VX1v5iBzpPYTRT8j+2eOBC/A5HvmH/VHFkIR6n3uOpt6Y9 ikjgEnKURjjt2EkU8M3eJAVGcby3ryDwwe0W2dvnRZk5F4CAlm4fgc8nFu9xJKD0e/Em N17d1PJ+vmA0KZFMo9vL6iR98yeuLoaY0vsRldCOmokcR7aAK1QSoXKXy72n0fDP8cN0 nvXA== MIME-Version: 1.0 X-Received: by 10.202.60.7 with SMTP id j7mr2824883oia.79.1432827521882; Thu, 28 May 2015 08:38:41 -0700 (PDT) Received: by 10.76.105.138 with HTTP; Thu, 28 May 2015 08:38:41 -0700 (PDT) In-Reply-To: References: <57F6A61F-5629-4D11-A78C-397DBB4E8381@inventum.net> <20150528075244.469b8557@urahara> Date: Thu, 28 May 2015 11:38:41 -0400 Message-ID: From: Kyle Larose To: Matt Laswell 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:38:43 -0000 I'm fairly new to dpdk, so I may be completely out to lunch on this, but here's an idea to possibly improve performance compared to a straight copy of the entire packet. If this idea makes sense, perhaps it could be added to the mbuf library as an extension of the clone functionality? If you are only modifying the headers (say the Ethernet header), is it possible to make a copy of only the first N bytes (say 32 bytes)? For example, you make two new "main" mbufs, which contain duplicate metadata, and a copy of the first 32 bytes of the packet. Call them A and B. Have both A and B chain to the original mbuf (call it O), which is reference counted as with the normal clone functionality. Then, you adjust the O such that its start data is 32 bytes into the packet. When you transmit A, it will send its own copy of the 32 bytes, plus the unaltered remaining data contained in O. A will be freed, and the refcount of O decremented. When you transmit B, it will work the same as with the previous one, except that when the refcount on O is decremented, it reaches zero and it is freed as well. I'm not sure if this makes sense in all cases (for example, maybe it's just faster to allocate separate mbufs for 64-byte packets). Perhaps that could also be handled transparently underneath the hood. Thoughts? Thanks, Kyle On Thu, May 28, 2015 at 11:10 AM, Matt Laswell wrote: > 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) > > >