From: Daniel Kaminsky <daniel.kaminsky@infinitelocality.com>
To: Prashant Upadhyaya <prashant.upadhyaya@aricent.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Request for a feature in PMD
Date: Sun, 27 Oct 2013 15:38:27 +0300 [thread overview]
Message-ID: <CA+8v-JzixyNb1+8dfeK0tkdm5hfdMsmjwsP_stx3arAGNrmuEA@mail.gmail.com> (raw)
In-Reply-To: <C7CE7EEF248E2B48BBA63D0ABEEE700C43EA705F70@GUREXMB01.ASIAN.AD.ARICENT.COM>
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.
>
> ===============================================================================
>
next prev parent reply other threads:[~2013-10-27 12:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-27 11:06 Prashant Upadhyaya
2013-10-27 12:38 ` Daniel Kaminsky [this message]
2013-10-30 6:08 ` Prashant Upadhyaya
2013-10-27 13:28 ` Gal Sagie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+8v-JzixyNb1+8dfeK0tkdm5hfdMsmjwsP_stx3arAGNrmuEA@mail.gmail.com \
--to=daniel.kaminsky@infinitelocality.com \
--cc=dev@dpdk.org \
--cc=prashant.upadhyaya@aricent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).