From mboxrd@z Thu Jan 1 00:00:00 1970 From: Prashant Upadhyaya Subject: Re: Request for a feature in PMD Date: Wed, 30 Oct 2013 11:38:23 +0530 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Daniel Kaminsky Return-path: In-Reply-To: Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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-bIuJOMs36akdlAAv9/cgxFaTQe2KTcn/@public.gmane.org] Sent: Sunday, October 27, 2013 6:08 PM To: Prashant Upadhyaya Cc: dev-VfR2kkLFssw@public.gmane.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