[dpdk-dev] Request for a feature in PMD

Daniel Kaminsky daniel.kaminsky at infinitelocality.com
Sun Oct 27 13:38:27 CET 2013


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 at 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.
>
> ===============================================================================
>


More information about the dev mailing list