DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Request for a feature in PMD
@ 2013-10-27 11:06 Prashant Upadhyaya
  2013-10-27 12:38 ` Daniel Kaminsky
  2013-10-27 13:28 ` Gal Sagie
  0 siblings, 2 replies; 4+ messages in thread
From: Prashant Upadhyaya @ 2013-10-27 11:06 UTC (permalink / raw)
  To: dev

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] Request for a feature in PMD
  2013-10-27 11:06 [dpdk-dev] Request for a feature in PMD Prashant Upadhyaya
@ 2013-10-27 12:38 ` Daniel Kaminsky
  2013-10-30  6:08   ` Prashant Upadhyaya
  2013-10-27 13:28 ` Gal Sagie
  1 sibling, 1 reply; 4+ messages in thread
From: Daniel Kaminsky @ 2013-10-27 12:38 UTC (permalink / raw)
  To: Prashant Upadhyaya; +Cc: dev

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] Request for a feature in PMD
  2013-10-27 11:06 [dpdk-dev] Request for a feature in PMD Prashant Upadhyaya
  2013-10-27 12:38 ` Daniel Kaminsky
@ 2013-10-27 13:28 ` Gal Sagie
  1 sibling, 0 replies; 4+ messages in thread
From: Gal Sagie @ 2013-10-27 13:28 UTC (permalink / raw)
  To: Prashant Upadhyaya; +Cc: dev

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] Request for a feature in PMD
  2013-10-27 12:38 ` Daniel Kaminsky
@ 2013-10-30  6:08   ` Prashant Upadhyaya
  0 siblings, 0 replies; 4+ messages in thread
From: Prashant Upadhyaya @ 2013-10-30  6:08 UTC (permalink / raw)
  To: Daniel Kaminsky; +Cc: 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_pktmbuf_free automatically decreases it by 1 and frees the packet only when the 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 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<mailto: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.
===============================================================================





===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-10-30  6:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-27 11:06 [dpdk-dev] Request for a feature in PMD Prashant Upadhyaya
2013-10-27 12:38 ` Daniel Kaminsky
2013-10-30  6:08   ` Prashant Upadhyaya
2013-10-27 13:28 ` Gal Sagie

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).