On Thu, Oct 23, 2014 at 5:18 PM, Jay Rolette <rolette at 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 >
