DPDK usage discussions
 help / color / mirror / Atom feed
From: "Wiles, Keith" <keith.wiles@intel.com>
To: Sofia Baran <sofia.baran@gmx.net>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] dpdk and bulk data (video/audio)
Date: Mon, 10 Sep 2018 12:51:50 +0000	[thread overview]
Message-ID: <73D04E54-F6CC-41C3-A622-744B88592AC5@intel.com> (raw)
In-Reply-To: <bd7bd47f-0084-f6b2-6cd0-cc34399ed622@gmx.net>



> On Sep 10, 2018, at 6:28 AM, Sofia Baran <sofia.baran@gmx.net> wrote:
> 
> 
> Hi All,
> 
> I want/try to us DPDK for transferring larger amount of data, e.g. video frames which usually are stored within memory buffers with sizes of several MB (remark: by using huges pages, these buffers could be physically contiguous).
> 
> When looking at the DPDK documentation, library APIs and examples, I can't find a way/hint how to transfer larger buffers using DPDK without copying the video buffer fragments to the payload sections of the mbufs - which results in high CPU loads.
> 
> Within the ip_fragmentation example indirect mbufs are used, pointing to the payload section of a direct mbuf (holding the header). But in my understanding the maximum size of a mbuf payload is 65KB (uint16_t)!?

It is true that mbufs only hold (64K - 1). The concept of mbufs is normally an ethernet packet and they are limited to 64K.

You can create a small mbuf (128 bytes) then set offset/data in the mbuf to point to the video buffer only if you can find the physical memory address for the data. The mbuf normally holds the physical address of the mbuf->data not the attached buffer in this case. This of course means you have to manage the mbuf internal structure members yourself and be very careful you do not rearrange the mbuf members as that can cause a performance problem.

> 
> I'm pretty new to DPDK so maybe I missed something. I hope that someone can provide me some hits how to avoid copying the entire payload.
> 
> Thanks
> Sofia Baran
> 
> 

Regards,
Keith

  reply	other threads:[~2018-09-10 12:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 11:28 Sofia Baran
2018-09-10 12:51 ` Wiles, Keith [this message]
2018-09-10 21:46   ` Trahe, Fiona
2018-09-13  9:54     ` Sofia Baran

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=73D04E54-F6CC-41C3-A622-744B88592AC5@intel.com \
    --to=keith.wiles@intel.com \
    --cc=sofia.baran@gmx.net \
    --cc=users@dpdk.org \
    /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).