From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by dpdk.org (Postfix) with ESMTP id CD1747E99 for ; Thu, 23 Oct 2014 16:10:01 +0200 (CEST) Received: by mail-yh0-f43.google.com with SMTP id z6so932320yhz.16 for ; Thu, 23 Oct 2014 07:18:26 -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:content-type; bh=MEe4/LIZpL+kSAqAUk7Oufekt9ELpqOYSIYC3MA/hjI=; b=JQCzQGViXTE6TjcUx+bSkhMofSLQj6qJGfXtrWeAD5CPFr83MSLCQ1r4pqSLFoyiSr xvfiizEx2YY30b3vzNaTPkSYTbBI13rDw6yaJ6HRZkVM2qAxgBRiGmWEMWw4Dsa8Ko5E Z7lJtpSMN0Zk/HjyK93UbNr9lKAu4i3pJiPkPiFKUKzjjtAVeGfa1qOg8J2OniOqMzta HoJQqfxEwteMi7U3U8qEX/Gk2xkaGBcLjOSm1Lwsb4nFxiTImxzOynx78BQUYsJ6S00b 8BmtAcL8iV+AGHFwg3t4XD3qVxVg0R9l4abjwNHaQ0Px6b3xaj1oXTe7GI7HZt2PAqXu 7K+w== X-Gm-Message-State: ALoCoQkNjLfDvr4hF+TSGOepicUSEvpjD/eJPbYTgUERD3NnkKP+bln2bqf7dKAiTiC6x1bm9BeD MIME-Version: 1.0 X-Received: by 10.170.202.196 with SMTP id t187mr297560yke.36.1414073906250; Thu, 23 Oct 2014 07:18:26 -0700 (PDT) Received: by 10.170.84.10 with HTTP; Thu, 23 Oct 2014 07:18:26 -0700 (PDT) In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54C361DF@IRSMSX102.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54C361DF@IRSMSX102.ger.corp.intel.com> Date: Thu, 23 Oct 2014 09:18:26 -0500 Message-ID: From: Jay Rolette To: "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [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:10:02 -0000 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. *> 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