DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices
Date: Fri, 6 Jun 2014 16:30:50 -0400	[thread overview]
Message-ID: <20140606203050.GB2543@hmsreliant.think-freely.org> (raw)
In-Reply-To: <1402082754-12921-1-git-send-email-linville@tuxdriver.com>

On Fri, Jun 06, 2014 at 03:25:54PM -0400, John W. Linville wrote:
> This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> socket.  The current implementation uses mmap'ed ring buffers to
> limit copying and user/kernel transitions.  The intent is also to take
> advantage of fanout and any future AF_PACKET optimizations as well.
> 
> This is intended to provide a means for using DPDK on a broad range
> of hardware without hardware-specifi PMDs and hopefully with better
> performance than what PCAP offers in Linux.  This might be useful
> as a development platform for DPDK applications when DPDK-supported
> hardware is expensive or unavailable.
> 
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> I've been toying with this for a while without a lot of progress.
> I was about to post the original RFC patch just as the PMD
> initialization flows got rewritten.  I set this down while that was
> settling-out, and only just recently got back to it.
> 
> Anyway, I figure it is better to get this out now and let people
> comment on it and/or get some use out of it if they can.  I have
> posted this as RFC as it has only had very limited testing locally
> and I'm sure it still could use some clean-ups and improvements
> (like parameterizing block/frame size/count).
> 
Looks pretty good.  I'll be interested to see how much beter we can do over
standard pcap when we turn on the features like fanout and increased memory
sizing.


One thought: Its not a feature, but is there advantage to making the transmit
batch size configurable?  e.g. how many packets you queue up for transmit in a
given memory buffer before calling send?  If you couple that with a timer, you
could trade of some initial latency for higher overall througput, as it reduces
the number of syscall traps you have to make.

Neil

  parent reply	other threads:[~2014-06-06 20:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-06 19:25 John W. Linville
2014-06-06 19:47 ` Chris Wright
2014-06-06 19:57   ` John W. Linville
2014-06-06 20:04     ` Richardson, Bruce
2014-06-06 20:06     ` Chris Wright
2014-06-06 20:30 ` Neil Horman [this message]
2014-06-06 20:36   ` John W. Linville
2014-06-06 20:51     ` Neil Horman

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=20140606203050.GB2543@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=linville@tuxdriver.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).