From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by dpdk.org (Postfix) with ESMTP id 18EE4DE4 for ; Wed, 30 Oct 2013 07:07:51 +0100 (CET) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 34D8D36B80; Wed, 30 Oct 2013 11:38:24 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 1B3C936B7E; Wed, 30 Oct 2013 11:38:24 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 30 Oct 2013 11:38:24 +0530 From: Prashant Upadhyaya To: Daniel Kaminsky Date: Wed, 30 Oct 2013 11:38:23 +0530 Thread-Topic: [dpdk-dev] Request for a feature in PMD Thread-Index: Ac7TFkSIqAbnOC9HRCqCSOjaPWAIjwCH6Rhg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-TM-AS-MML: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 30 Oct 2013 06:07:51 -0000 Hi Gal, Daniel, Etai, Thanks for your suggestion. I could use the refcnt for my usecase effectively. I just bumped up the refcount by 1 when I don't want to free it. The rte_pk= tmbuf_free automatically decreases it by 1 and frees the packet only when t= he refcount reaches zero. So this is a pretty neat use of refcnt. I wonder if this usecase should be = documented in the userguide somewhere. Regards -Prashant From: Daniel Kaminsky [mailto:daniel.kaminsky@infinitelocality.com] Sent: Sunday, October 27, 2013 6:08 PM To: Prashant Upadhyaya Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Request for a feature in PMD Hi Prashant, >>From your description it seems that you can use rte pktmbuf_refcnt_update m= ethod. Increase the reference count by one before sending the mbuf, and dec= rease it when you finish with it. Regards, Daniel Kaminsky On Sun, Oct 27, 2013 at 2:06 PM, Prashant Upadhyaya > 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 somewh= ere 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 u= ses the PKO api's to send a packet out. PKO is the packet output unit of Cavium processor to which you submit the b= uffers 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 t= he buffer with the help of a bit. This is particularly useful when the same buffer has to be sent out multipl= e times. Now to port the above usecase in DPDK, I had to make a copy of the buffer a= nd 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 pena= lty. It would be nice if PMD itself gives this facility. Would request the opinion of PMD developers regarding the above. Regards -Prashant =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D