DPDK patches and discussions
 help / color / mirror / Atom feed
From: Alex Markuze <alex@weka.io>
To: Jay Rolette <rolette@infiniteio.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Fwd: [dpdk-announce] DPDK Features for Q1 2015
Date: Thu, 23 Oct 2014 17:52:42 +0300
Message-ID: <CAKfHP0W5JaYC19yGOVGqCoGoMCn_YoTBCx-OD92YgMhfEgxt2w@mail.gmail.com> (raw)
In-Reply-To: <CADNuJVq=EZmEuF=Bm+rmEjxDBPFJi3A_PaLAOB6KuyU6CyaNLg@mail.gmail.com>

On Thu, Oct 23, 2014 at 5:18 PM, Jay Rolette <rolette@infiniteio.com> wrote:

> Tim,
> Thanks for sharing this. If nothing else, I wanted to at least provide some
> feedback on the parts that look useful to me for my applications/product.
> Bits that make me interested in the release:
> *> 2.0 (Q1 2015) DPDK Features:> Bifurcated Driver: With the Bifurcated
> Driver, the kernel will retain direct control of the NIC, and will assign
> specific queue pairs to DPDK. Configuration of the NIC is controlled by the
> kernel via ethtool.*
> Having NIC configuration, port stats, etc. available via the normal Linux
> tools is very helpful - particularly on new products just getting started
> with DPDK.
> *> Packet Reordering: Assign a sequence number to packets on Rx, and then
> provide the ability to reorder on Tx to preserve the original order.*
> This could be extremely useful but it depends on where it goes. The current
> design being discussed seems fundamentally flawed to me. See the thread on
> the RFC for details.
> *> Packet Distributor (phase 2): Implement the following enhancements to
> the Packet Distributor that was originally delivered in the DPDK 1.7
> release: performance improvements; the ability for packets from a flow to
> be processed by multiple worker cores in parallel and then reordered on Tx
> using the Packet Reordering feature; the ability to have multiple
> Distributors which share Worker cores.*
> TBD on this for me. The 1.0 version of our product is based on DPDK 1.6 and
> I haven't had a chance to look at what is happening with Packet Distributor
> yet. An area of potential interest at least.
> *> Cuckoo Hash: A new hash algorithm was implemented as part of the Cuckoo
> Switch project (see http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf
> <http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf>), and shows some
> promising performance results. This needs to be modified to make it more
> generic, and then incorporated into DPDK.*
> More performance == creamy goodness, especially if it is in the plumbing
> and doesn't require significant app changes.
> *> Interrupt mode for PMD: Allow DPDK process to transition to interrupt
> mode when load is low so that other processes can run, or else power can be
> saved. This will increase latency/jitter.*
> Yes! I don't care about power savings, but I do care about giving a good
> product impression in the lab during evals without having to sacrifice
> overall system performance when under load. Hybrid drivers that use
> interrupts when load is low and poll-mode when loaded are ideal, IMO.
> It seems an odd thing, but during lab testing, it is normal for customers
> to fire the box up and just start running pings or some other low volume
> traffic through the box. If the PMDs are configured to batch in sizes
> optimal for best performance under load, the system can look *really* bad
> in these initial tests. We go through a fair bit of gymnastics right now to
> work around this without just giving up on batching in the PMDs.

> *>> I second this, DPDK is great for kernel bypass and zero-copy. But not
> all apps are network bound, thus interrupt mode is something that is
> extremely helpful.

> *> DPDK Headroom: Provide a mechanism to indicate how much headroom (spare
> capacity) exists in a DPDK process.*
> Very helpful in the field. Anything that helps customers understand how
> much headroom is left on their box before they need to take action is a
> huge win. CPU utilization is a bad indicator, especially with a PMD
> architecture.
> Hope this type of feedback is helpful.
> Regards,
> Jay

      reply	other threads:[~2014-10-23 14:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 13:48 [dpdk-dev] " O'driscoll, Tim
2014-10-22 14:20 ` [dpdk-dev] " Thomas Monjalon
2014-10-22 14:44   ` Zhou, Danny
2014-10-22 15:05     ` Liang, Cunming
2014-10-22 16:10 ` [dpdk-dev] [dpdk-announce] " Luke Gorrie
2014-10-23 12:29   ` O'driscoll, Tim
2014-10-22 19:22 ` Matthew Hall
2014-10-24  8:10   ` O'driscoll, Tim
2014-10-24 10:10     ` Thomas Monjalon
2014-10-24 19:02       ` Matthew Hall
2014-10-24 19:01     ` Matthew Hall
2014-10-23  3:06 ` Tetsuya Mukawa
2014-10-23 10:04   ` O'driscoll, Tim
2014-10-23  3:17 ` Tetsuya Mukawa
2014-10-23 11:27   ` O'driscoll, Tim
2014-10-31 22:05   ` Xie, Huawei
2014-11-02 12:50     ` Tetsuya Mukawa
2014-10-23 14:18 ` [dpdk-dev] Fwd: " Jay Rolette
2014-10-23 14:52   ` Alex Markuze [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKfHP0W5JaYC19yGOVGqCoGoMCn_YoTBCx-OD92YgMhfEgxt2w@mail.gmail.com \
    --to=alex@weka.io \
    --cc=dev@dpdk.org \
    --cc=rolette@infiniteio.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git