[dpdk-dev] [PATCH v1] doc: fix release notes for 16.11

[dpdk-dev] [PATCH v1] doc: fix release notes for 16.11

[John McNamara]

Fix grammar, spelling and formatting of DPDK 16.11 release notes.

Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
 doc/guides/rel_notes/release_16_11.rst | 171 ++++++++++++++++-----------------
 1 file changed, 83 insertions(+), 88 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index 365b5a3..6f40f59 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -42,7 +42,7 @@ New Features
   * Added a new function ``rte_pktmbuf_read()`` to read the packet data from an
     mbuf chain, linearizing if required.
   * Added a new function ``rte_net_get_ptype()`` to parse an Ethernet packet
-    in an mbuf chain and retrieve its packet type by software.
+    in an mbuf chain and retrieve its packet type from software.
   * Added new functions ``rte_get_ptype_*()`` to dump a packet type as a string.
 
 * **Improved offloads support in mbuf.**
@@ -52,102 +52,108 @@ New Features
   * Added new Rx checksum flags in mbufs to describe more states: unknown,
     good, bad, or not present (useful for virtual drivers). This modification
     was done for IP and L4.
-  * Added a new RX LRO mbuf flag, used when packets are coalesced. This
+  * Added a new Rx LRO mbuf flag, used when packets are coalesced. This
     flag indicates that the segment size of original packets is known.
 
-* **Added vhost-user dequeue zero copy support**
+* **Added vhost-user dequeue zero copy support.**
 
-  The copy in dequeue path is saved, which is meant to improve the performance.
+  The copy in the dequeue path is avoided in order to improve the performance.
   In the VM2VM case, the boost is quite impressive. The bigger the packet size,
-  the bigger performance boost you may get. However, for VM2NIC case, there
-  are some limitations, yet the boost is not that impressive as VM2VM case.
+  the bigger performance boost you may get. However, for the VM2NIC case, there
+  are some limitations, so the boost is not as  impressive as the VM2VM case.
   It may even drop quite a bit for small packets.
 
-  For such reason, this feature is disabled by default. It can be enabled when
-  ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY`` flag is given. Check the vhost section
-  at programming guide for more information.
+  For that reason, this feature is disabled by default. It can be enabled when
+  the ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY`` flag is set. Check the VHost section
+  of the Programming Guide for more information.
 
 * **Added vhost-user indirect descriptors support.**
 
-  If indirect descriptor feature is negotiated, each packet sent by the guest
-  will take exactly one slot in the enqueue virtqueue. Without the feature, in
-  current version, even 64 bytes packets take two slots with Virtio PMD on guest
+  If the indirect descriptor feature is enabled, each packet sent by the guest
+  will take exactly one slot in the enqueue virtqueue. Without this feature, as in
+  the current version, even 64 bytes packets take two slots with Virtio PMD on guest
   side.
 
   The main impact is better performance for 0% packet loss use-cases, as it
   behaves as if the virtqueue size was enlarged, so more packets can be buffered
-  in case of system perturbations. On the downside, small performance degradation
-  is measured when running micro-benchmarks.
+  in the case of system perturbations. On the downside, small performance degradations
+  were measured when running micro-benchmarks.
 
 * **Added vhost PMD xstats.**
 
-  Added extended statistics to vhost PMD from per port perspective.
+  Added extended statistics to vhost PMD from a per port perspective.
 
 * **Supported offloads with virtio.**
 
-  * Rx/Tx checksums
-  * LRO
-  * TSO
+  Added support for the following offloads in virtio:
+
+  * Rx/Tx checksums.
+  * LRO.
+  * TSO.
 
 * **Added virtio NEON support for ARM.**
 
+  Added NEON support for ARM based virtio.
+
 * **Updated the ixgbe base driver.**
 
   Updated the ixgbe base driver, including the following changes:
 
-  * add X550em_a 10G PHY support
-  * support flow control auto negotiation for X550em_a 1G PHY
-  * add X550em_a FW ALEF support
-  * increase mailbox version to ixgbe_mbox_api_13
-  * add two MAC ops for Hyper-V support
+  * Added X550em_a 10G PHY support.
+  * Added support for flow control auto negotiation for X550em_a 1G PHY.
+  * Added X550em_a FW ALEF support.
+  * Increased mailbox version to ``ixgbe_mbox_api_13``.
+  * Added two MAC operations for Hyper-V support.
 
-* **Added API's for VF management to the ixgbe PMD.**
+* **Added APIs for VF management to the ixgbe PMD.**
 
-  Eight new API's have been added to the ixgbe PMD for VF management from the PF.
+  Eight new APIs have been added to the ixgbe PMD for VF management from the PF.
   The declarations for the API's can be found in ``rte_pmd_ixgbe.h``.
 
 * **Updated the enic driver.**
 
-  * Use interrupt for link status checking instead of polling
-  * More flow director modes on UCS Blade with firmware version >= 2.0(13e)
-  * Full support for MTU update
-  * Support for rte_eth_rx_queue_count function
+  * Added update to use interrupt for link status checking instead of polling.
+  * Added more flow director modes on UCS Blade with firmware version >= 2.0(13e).
+  * Added full support for MTU update.
+  * Added support for the ``rte_eth_rx_queue_count`` function.
 
 * **Updated the mlx5 driver.**
 
-  * Add support for RSS hash result
-  * Several performance improvements
-  * Several bug fixes
+  * Added support for RSS hash results.
+  * Added several performance improvements.
+  * Added several bug fixes.
 
 * **Updated the QAT PMD.**
 
-  The QAT PMD was updated with following support:
+  The QAT PMD was updated with additional support for:
 
-  * MD5_HMAC algorithm
-  * SHA224-HMAC algorithm
-  * SHA384-HMAC algorithm
-  * GMAC algorithm
-  * KASUMI (F8 and F9) algorithm
-  * 3DES algorithm
-  * NULL algorithm
-  * C3XXX device
-  * C62XX device
+  * MD5_HMAC algorithm.
+  * SHA224-HMAC algorithm.
+  * SHA384-HMAC algorithm.
+  * GMAC algorithm.
+  * KASUMI (F8 and F9) algorithm.
+  * 3DES algorithm.
+  * NULL algorithm.
+  * C3XXX device.
+  * C62XX device.
 
 * **Added openssl PMD.**
 
-  A new crypto PMD has been added, which provides several ciphering and hashing.
-  All cryptography operations are using Openssl library crypto API.
+  A new crypto PMD has been added, which provides several ciphering and hashing algorithms.
+  All cryptography operations use the Openssl library crypto API.
+
+* **Updated the IPsec example.**
 
-* **Updated the IPsec example with following support:**
+  Updated the IPsec example with the following support:
 
-  * configuration file
-  * AES CBC IV generation with cipher forward function
-  * AES GCM/CTR mode
+  * Configuration file support.
+  * AES CBC IV generation with cipher forward function.
+  * AES GCM/CTR mode.
 
 * **Added support for new gcc -march option.**
 
   The GCC 4.9 ``-march`` option supports the Intel processor code names.
-  The config option ``RTE_MACHINE`` can be used to pass code names to the compiler as ``-march`` flag.
+  The config option ``RTE_MACHINE`` can be used to pass code names to the compiler via the ``-march`` flag.
 
 
 Resolved Issues
@@ -164,10 +170,6 @@ Resolved Issues
    This section is a comment. Make sure to start the actual text at the margin.
 
 
-EAL
-~~~
-
-
 Drivers
 ~~~~~~~
 
@@ -178,17 +180,6 @@ Drivers
 * **enic: Fixed high driver overhead when servicing Rx queues beyond the first.**
 
 
-Libraries
-~~~~~~~~~
-
-
-Examples
-~~~~~~~~
-
-
-Other
-~~~~~
-
 
 Known Issues
 ------------
@@ -204,14 +195,14 @@ Known Issues
 
 * **L3fwd-power app does not work properly when Rx vector is enabled.**
 
-  Using some drivers with vector enabled, makes L3fwd-power app not work
-  properly, since the queue monitoring works differently when using
-  scalar compared to vector, making the frequency scaling not to work correctly.
-  In addition, L3fwd-power requires the mbuf to have correct packet type,
-  but in some drivers, the vector mode must be disabled for this.
+  The L3fwd-power app doesn't work properly with some drivers in vector mode
+  since the queue monitoring works differently between scalar and vector modes
+  leading to incorrect frequency scaling. In addition, L3fwd-power application
+  requires the mbuf to have correct packet type set but in some drivers the
+  vector mode must be disabled for this.
 
   Therefore, in order to use L3fwd-power, vector mode should be disabled
-  from the config file.
+  via the config file.
 
 
 API Changes
@@ -224,38 +215,42 @@ API Changes
 
    This section is a comment. Make sure to start the actual text at the margin.
 
-* The driver names have been changed. It especially impacts ``--vdev`` arguments.
-  Examples: ``eth_pcap`` becomes ``net_pcap``
-  and ``cryptodev_aesni_mb_pmd`` becomes ``crypto_aesni_mb``.
+* The driver naming convention has been changed to make them more
+  consistent. It especially impacts ``--vdev`` arguments. For example
+  ``eth_pcap`` becomes ``net_pcap`` and ``cryptodev_aesni_mb_pmd`` becomes
+  ``crypto_aesni_mb``.
+
+  For backward compatibility an alias feature has been enabled to support the
+  original names.
 
-* The log history is removed.
+* The log history has been removed.
 
 * The ``rte_ivshmem`` feature (including library and EAL code) has been removed
   in 16.11 because it had some design issues which were not planned to be fixed.
 
 * The ``file_name`` data type of ``struct rte_port_source_params`` and
-  ``struct rte_port_sink_params`` is changed from `char *`` to ``const char *``.
+  ``struct rte_port_sink_params`` is changed from ``char *`` to ``const char *``.
 
-* **Improved device/driver hierarchy and generalized hotplugging**
+* **Improved device/driver hierarchy and generalized hotplugging.**
 
-  Device and driver relationship has been restructured by introducing generic
-  classes. This paves way for having PCI, VDEV and other device types as
-  just instantiated objects rather than classes in themselves. Hotplugging too
-  has been generalized into EAL so that ethernet or crypto devices can use the
+  The device and driver relationship has been restructured by introducing generic
+  classes. This paves the way for having PCI, VDEV and other device types as
+  instantiated objects rather than classes in themselves. Hotplugging has also
+  been generalized into EAL so that Ethernet or crypto devices can use the
   common infrastructure.
 
-  * removed ``pmd_type`` as way of segregation of devices
-  * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
+  * Removed ``pmd_type`` as a way of segregation of devices.
+  * Moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
     ``rte_pci_driver``. These can now be used by any instantiated object of
     ``rte_driver``.
-  * added ``rte_device`` class and all PCI and VDEV devices inherit from it
-  * renamed devinit/devuninit handlers to probe/remove to make it more
-    semantically correct with respect to device<=>driver relationship
-  * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
+  * Added ``rte_device`` class and all PCI and VDEV devices inherit from it
+  * Renamed devinit/devuninit handlers to probe/remove to make it more
+    semantically correct with respect to the device <=> driver relationship.
+  * Moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
     APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
-  * helpers and support macros have been renamed to make them more synonymous
+  * Renamed helpers and support macros to make them more synonymous
     with their device types
-    (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``)
+    (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``).
   * Device naming functions have been generalized from ethdev and cryptodev
     to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
     unique device name from PCI Domain-BDF description.
-- 
2.7.4

Re: [dpdk-dev] [PATCH v1] doc: fix release notes for 16.11

[Shreyansh Jain]

On Friday 11 November 2016 05:34 PM, John McNamara wrote:
[...]
> -* **Improved device/driver hierarchy and generalized hotplugging**
> +* **Improved device/driver hierarchy and generalized hotplugging.**
>
> -  Device and driver relationship has been restructured by introducing generic
> -  classes. This paves way for having PCI, VDEV and other device types as
> -  just instantiated objects rather than classes in themselves. Hotplugging too
> -  has been generalized into EAL so that ethernet or crypto devices can use the
> +  The device and driver relationship has been restructured by introducing generic
> +  classes. This paves the way for having PCI, VDEV and other device types as
> +  instantiated objects rather than classes in themselves. Hotplugging has also
> +  been generalized into EAL so that Ethernet or crypto devices can use the
>    common infrastructure.
>
> -  * removed ``pmd_type`` as way of segregation of devices
> -  * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
> +  * Removed ``pmd_type`` as a way of segregation of devices.
> +  * Moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
>      ``rte_pci_driver``. These can now be used by any instantiated object of
>      ``rte_driver``.
> -  * added ``rte_device`` class and all PCI and VDEV devices inherit from it
> -  * renamed devinit/devuninit handlers to probe/remove to make it more
> -    semantically correct with respect to device<=>driver relationship
> -  * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
> +  * Added ``rte_device`` class and all PCI and VDEV devices inherit from it
> +  * Renamed devinit/devuninit handlers to probe/remove to make it more
> +    semantically correct with respect to the device <=> driver relationship.
> +  * Moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
>      APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
> -  * helpers and support macros have been renamed to make them more synonymous
> +  * Renamed helpers and support macros to make them more synonymous
>      with their device types
> -    (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``)
> +    (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``).
>    * Device naming functions have been generalized from ethdev and cryptodev
>      to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
>      unique device name from PCI Domain-BDF description.

If it is possible to have a Reviewed-by for a particular part of a patch:

Reviewed-by: Shreyansh Jain <shreyansh.jain@nxp.com>

Re: [dpdk-dev] [PATCH v1] doc: fix release notes for 16.11

[Thomas Monjalon]

2016-11-11 12:04, John McNamara:
> Fix grammar, spelling and formatting of DPDK 16.11 release notes.
> 
> Signed-off-by: John McNamara <john.mcnamara@intel.com>

Applied, thanks