Re: [dpdk-dev] Fwd: [dpdk-announce] DPDK Features for Q1 2015

[Alex Markuze <alex@weka.io>]

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
>