From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by dpdk.org (Postfix) with ESMTP id 02D90DE4 for ; Sun, 27 Oct 2013 14:27:34 +0100 (CET) Received: by mail-ie0-f178.google.com with SMTP id x13so9394668ief.23 for ; Sun, 27 Oct 2013 06:28:25 -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=79JSR0ru3p6UXI7JJjPL4iU61TYTHj4x+zVmoFwHC78=; b=oN3tcDdJbbTKTKVYG4D+qJ6dYiDLL9S1J92GzTCgFHFDGkiZ+AZPXjvq+AvJ5EQ0xm ouSCJJ6SjQn4tUKNJNgP2wGvBjwBsAV7uI55NjC+pDDh+dqOOONLe0vE21Xd9GP0tsQa nCTU0p8hvpLL6DnWI9MVMO24UIZvjW3Hsdqci9scIt9TQ20X7Ybvg+/1jND9NFbbCWjo 7l5VIIhwOVnFN70HdR+uXvJ8COCdSHEsVR5AhqKNKk+Wm+i/5Y4hre5y3iKFUuqwn5wn FVXaWVnQvkWzTsb1aUfnRy0RjsHm4pGL9qjWevpbZlvzp4yLz8b4rwaxKq1X6eNDKRlx yfYg== MIME-Version: 1.0 X-Received: by 10.50.16.65 with SMTP id e1mr5181253igd.19.1382880504966; Sun, 27 Oct 2013 06:28:24 -0700 (PDT) Received: by 10.42.69.9 with HTTP; Sun, 27 Oct 2013 06:28:24 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Oct 2013 15:28:24 +0200 Message-ID: From: Gal Sagie To: Prashant Upadhyaya Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Request for a feature in PMD 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: Sun, 27 Oct 2013 13:27:35 -0000 Hello Prashant, You can achieve this behavior, you can look at either the rte_mbuf clone API or look at the reference count field inside the mbuf structure. If you increase this ref count the TX function will not free your mbuf. (there are some API calls to update this variable) Gal. On Sun, Oct 27, 2013 at 1:06 PM, Prashant Upadhyaya < prashant.upadhyaya@aricent.com> wrote: > Hi, > > I have a feature request in the PMD. > > Today, when I want to send a packet out, I hand over an mbuf to the PMD > API. > The PMD API then takes care of transferring the data and free's the mbuf > to the relevant pool. > > What I am looking for is a facility that I should be able to specify > somewhere in the header of mbuf that the PMD API must not free this buffer > after doing the transmission. > The user will take care of freeing this buffer on his own depending on his > own application logic (ofcourse if the user does not do so, it is a bug in > his application for the buffer leak) > > Why do I want this ? I was porting a usecase from Cavium Octeon SDK which > uses the PKO api's to send a packet out. > PKO is the packet output unit of Cavium processor to which you submit the > buffers to send and it frees it for you (just like our PMD in DPDK) > However PKO API gives me a nice facility where I can tell PKO not to free > the buffer with the help of a bit. > This is particularly useful when the same buffer has to be sent out > multiple times. > > Now to port the above usecase in DPDK, I had to make a copy of the buffer > and submit it to the PMD (because it _will_ free it) to give the > application the similar flavour as PKO in DPDK. However the copy is a > performance penalty. It would be nice if PMD itself gives this facility. > > Would request the opinion of PMD developers regarding the above. > > Regards > -Prashant > > > > > > > =============================================================================== > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > > =============================================================================== > -- Best Regards , The G.