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
