From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id 191D937B2 for ; Fri, 14 Apr 2017 16:30:12 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id o21so51856559wrb.2 for ; Fri, 14 Apr 2017 07:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IV5z4IuHmzKqtpHsPryLlnHC2aW3cko/q1VZJ2jp3/o=; b=Kr3obJ4jAAbpyLsYm8iXe9YTxlmVkD0h2pt8DXiXKdmZPN/OFMqIQBVWkT3t2jAH5T EwbqyUNrvG2o3si2ADKMteRBmq8TiaF5tBviA4+OavL6yh2bd7pFotLSpHclb/gPpPwg 80csYZPnGimI7hjcH/UKE4e7EePwYBpaPlULMoTj3+eIAoCQA0azDYwyZ31RP0SyxyeD AAgc622+fq45s1+vjolYhbZxXUCmdGZPRm7VPGxL93BIxxfqTXD7gzVbE48jhP5aJqUP t3ABZ2xrqb3SziMUKD5OU27tz+W+r3P4uHyaIGOEsdBtpY90LB93AiosC+f5JjjAFy66 jbOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IV5z4IuHmzKqtpHsPryLlnHC2aW3cko/q1VZJ2jp3/o=; b=FYYZsPq/cajgkSH9wEqNsanr+M8zotgiqqIDNHAfbhXi54W11JbaS2Y+le0SR6W08f P3ftTAVfbJBP1rDYeGcVV8icTg1CuANLU9zCHWGd+NbmzsfWIyOwq+kwsLx3b1VcXyuc nZMfn2YyKJD9e/I9I3Uh6g7lGl1ric3LmcFOc89E9V9/vVrcnl4CYfe3dbI4DqVah0hQ VF/VORMuYaCkLGhHloKDg/b/9T9RG1B8P0z2UWmIeHBlakawjQs41FFgUCWUMqs5FX0F PlMAx5JlwrLzWBe6Yqc937BBnaddwAiI6Gjnn3kYxmsvJlhAnvparFy5uM2WE/sDeO93 LteQ== X-Gm-Message-State: AN3rC/4uiuYcMOn2ZyTWnq6jI1L1XT3DV251+1ssaWzed7JFEbCU5d2W gNEfleftiy4N9HIn X-Received: by 10.223.152.67 with SMTP id v61mr8158908wrb.8.1492180211068; Fri, 14 Apr 2017 07:30:11 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id a66sm2570648wrc.58.2017.04.14.07.30.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 07:30:10 -0700 (PDT) Date: Fri, 14 Apr 2017 16:30:02 +0200 From: Adrien Mazarguil To: "O'Driscoll, Tim" Cc: "dev@dpdk.org" Message-ID: <20170414143002.GN3790@6wind.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA75A65453@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA75A65453@IRSMSX108.ger.corp.intel.com> Subject: Re: [dpdk-dev] 17.08 Roadmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 14:30:12 -0000 On Fri, Apr 14, 2017 at 01:27:13PM +0000, O'Driscoll, Tim wrote: > Below are the features that we're planning to submit for the 17.08 release. We'll submit a patch to update the roadmap page with this info. > > It would be good if others are also willing to share their plans so that we can build up a complete picture of what's planned for 17.08 and make sure there's no duplication. > > Generic QoS API: The proposed API is currently being added to the next-tm repository (http://dpdk.org/browse/next/dpdk-next-tm/). In 17.08, implementations of that API will be added for I40E, IXGBE, and the existing software QoS implementation. The API will move from next-tm to the main DPDK repository. > > Support for IPFIX: An RFC will be created in the next few weeks to support IPFIX (IP Flow Information Export - see https://en.wikipedia.org/wiki/IP_Flow_Information_Export for details) within DPDK. The actual implementation of IPFIX will be the responsibility of the application, but a library will be proposed which will enable an application to implement an IPFIX Observation Point, Metering Process and Exporter Process. Depending on the response to this RFC, we'll consider implementing the IPFIX library for 17.08. > > GRO (Generic Receive Offload): Generic Receive Offload is a widely used SW-based offloading technique to reduce per-packet processing overhead. It improves performance by reassembling small packets into large ones. A new library will be added to DPDK which will implement GRO. > > Generic Flow Enhancements: The rte_flow API was added in 17.02 and implemented for IXGBE and I40E. Support will be added for IGB, and enhancements will also be implemented for IXGBE (NVGRE/L2 Tunnel filters). > > Add Packet Type Recognition to IXGBE Vector PMD: The I40E Vector PMD supports packet type recognition but the IXGBE vPMD doesn't. This is a problem for VPP (https://wiki.fd.io/view/VPP) as they have to add a patch on top of DPDK to implement this. > > VF Port Reset for IXGBE: This was implemented in 17.05 for I40E (see http://dpdk.org/ml/archives/dev/2017-April/063538.html). Support will be added for IXGBE in 17.08. > > Cryptodev Multi-Core SW Scheduler: The cryptodev scheduler was first introduced in 17.02 and further enhanced in 17.05. It will be enhanced again in 17.08 to support the ability to use a pool of cores for software crypto. This will allow sufficient capacity to be provisioned for encrypting/decrypting large flows in software. > > API to Configure Queue Regions for RSS: This provides support for configuration of queue regions for RSS, so that different traffic classes or different packet classification types to be separated into different queues. This will be implemented for I40E. About this last topic, do you mean devising a new API is necessary or do you plan to implement it through rte_flow? I'm asking as it looks like this is what the rte_flow RSS action is defined for, see [1]. The mlx5 PMD adds support for it in 17.05 [2]. I also intend to submit a few changes to rte_flow: - VLAN item fix (according to this thread [3]). Impacts PMDs that implement the VLAN and associated items. Not sure it can be accepted or 17.08 due to ABI breakage, but it will be submitted regardless. - A new isolated operation mode for rte_flow, guaranteeing applications can expect to receive packets from the flow rules they define *only* for complete control. No more "default" RX rules, RSS and so on. It means PMDs are free to reassign these resources to flow rules. No planned ABI breakage. [1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#action-rss [2] http://dpdk.org/browse/next/dpdk-next-net/commit/?id=1bfb7bb4423349ab13decead0af8ffd006e8e398 [3] http://dpdk.org/ml/archives/dev/2017-March/060231.html -- Adrien Mazarguil 6WIND