[dpdk-dev] Request for a feature in PMD

[Gal Sagie]

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



-- 
Best Regards ,

The G.