From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by dpdk.org (Postfix) with ESMTP id 4AD42DE4 for ; Sun, 27 Oct 2013 13:37:37 +0100 (CET) Received: by mail-vb0-f43.google.com with SMTP id g10so3820762vbg.2 for ; Sun, 27 Oct 2013 05:38:27 -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=AKsiRs7jlQaMhXsQVRNj1oywT9+gERUiVg3Ex17pKpQ=; b=UCaBhj3LNweND9BXhIghwkm1CGz1MKDevi1CIcOkn6syburiGp/pnwV6ybHfem5lR3 JbiXgXfj3n7C9jjkf55wQ8e4xfKimPc9rDDIjNldJITk3yu0Av7znFyl1kPhGKwCcBW3 v5o6Y8bpw4YFph9R6McOrTmD0dV9CQzt7UPprMLoSZQMFCP+Sx2Dz6WcKyQU0Q9wVGwx s/4AcrfZlfxceat5hb32pvNP6qw/hFmPycSDevgdybxarn1ijdYshOBo2qu4YLl3FWtI H8SliA0lNB9kVQKIQQ4wDM9yOYV9nPkniJAZc7h5dE+tQY4BzfD0tmkw3GykrqN5XRuc I3gA== X-Gm-Message-State: ALoCoQk4Tiw3ioQCPDoxSNSYABkh9RqbuH7ntR4Y+B3RUqLhp6T+2Qt/VZIlY5nuDXsdvE6JDKMp MIME-Version: 1.0 X-Received: by 10.220.183.199 with SMTP id ch7mr62985vcb.27.1382877507636; Sun, 27 Oct 2013 05:38:27 -0700 (PDT) Received: by 10.58.7.234 with HTTP; Sun, 27 Oct 2013 05:38:27 -0700 (PDT) X-Originating-IP: [84.109.83.45] In-Reply-To: References: Date: Sun, 27 Oct 2013 15:38:27 +0300 Message-ID: From: Daniel Kaminsky To: Prashant Upadhyaya X-Mailman-Approved-At: Sun, 27 Oct 2013 23:24:06 +0100 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 12:37:37 -0000 Hi Prashant, >>From your description it seems that you can use rte *pktmbuf_refcnt_update*method. Increase the reference count by one before sending the mbuf, and decrease it when you finish with it. Regards, Daniel Kaminsky On Sun, Oct 27, 2013 at 2: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. > > =============================================================================== >