From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by dpdk.org (Postfix) with ESMTP id A7A627E99 for ; Thu, 23 Oct 2014 16:44:18 +0200 (CEST) Received: by mail-lb0-f170.google.com with SMTP id u10so1216361lbd.1 for ; Thu, 23 Oct 2014 07:52:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YgCrFEuVNzP/RusAunG/eF7NyUnn3HIK88iVLK8p31c=; b=CvWwOMcExYOfDtThZlXUTo66HukMCXq7BeCeud0Y6TXZIrYky8ElCMyQQ4Ve/6goNU aSDh19Ee1xlZOodL9kMOWOXet7Amx1+T/nmZQ3wa6oOLqyzvMglxgIb7zRRS90hCSQCG mQF943AlnTSm3s+Gf0gKw68LTkMpfrGvan0/51T3bGO9fSJtHer67YQnwNvZg5fBQ5th QZguQKJJwaJ/dOE73ORz7u2+dwdpAiwfRi87xASuXH0iv/VJc3vVUjJ37asStgYyGsXw JRlIMMK6r2dBtTPWHicRYDTUz4R19qLRr/JH0WDsBN70lHaFlGONRefR4QeBwt2Eil9t ZosQ== X-Gm-Message-State: ALoCoQmIQFkP1/+0dP1q7LZU2rzIIH+E/narGeziHe/FIvBcEADmAvTvEKurY4SOC6fOTPGFvjJx MIME-Version: 1.0 X-Received: by 10.112.221.226 with SMTP id qh2mr5690904lbc.5.1414075962877; Thu, 23 Oct 2014 07:52:42 -0700 (PDT) Received: by 10.25.215.141 with HTTP; Thu, 23 Oct 2014 07:52:42 -0700 (PDT) In-Reply-To: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54C361DF@IRSMSX102.ger.corp.intel.com> Date: Thu, 23 Oct 2014 17:52:42 +0300 Message-ID: From: Alex Markuze To: Jay Rolette Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Fwd: [dpdk-announce] DPDK Features for Q1 2015 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:44:18 -0000 On Thu, Oct 23, 2014 at 5:18 PM, Jay Rolette 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 > ), 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 >