Re: [dpdk-dev] [PATCH] doc: add kni changes to release note

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 11/5/2018 6:29 PM, Dan Gora wrote:
> Add the new module parameter for the KNI kernel module, the new command
> line flag for the KNI sample application, and the new API function
> 'rte_kni_update_link()' to the release note.
> 
> Signed-off-by: Dan Gora <dg@adax.com>
> 
> ---
>  doc/guides/rel_notes/release_18_11.rst | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_18_11.rst b/doc/guides/rel_notes/release_18_11.rst
> index cfa92b8c0..43fe849db 100644
> --- a/doc/guides/rel_notes/release_18_11.rst
> +++ b/doc/guides/rel_notes/release_18_11.rst
> @@ -301,6 +301,16 @@ New Features
>    computation to the NIST Cryptographic Algorithm Validation Program (CAVP)
>    test vectors.
>  
> +* **Updated KNI kernel module and sample application.**
> +
> +  Updated the KNI kernel module with a new kernel module parameter,
> +  ``carrier=[on|off]`` to allow the user to control the default carrier
> +  state of KNI kernel network interfaces.
> +
> +  Added a new command line flag ``-m`` to the KNI sample application to
> +  monitor and automatically reflect the physical NIC carrier state to the
> +  KNI kernel network interface with the new ``rte_kni_update_link()`` API.
> +
>  
>  API Changes
>  -----------
> @@ -362,6 +372,9 @@ API Changes
>    and seen as invalid because of its state ``RTE_ETH_DEV_UNUSED``.
>    This new behaviour is enabled per driver for a migration period.
>  
> +* kni: Added the new API function ``rte_kni_update_link()`` to allow the user
> +  to set the carrier state of the KNI kernel network interface.
> +

It is good to document new API, which can be on "new features" section above, we
mostly don't document new APIs in "api changes" section, but also it is
important to document behavior change too.
Now by default kni interfaces will have carrier off, and there won't be any
traffic and people may get stuck, this is to help them, that is why I mentioned
sysfs interface, since this patch replaces that one, can you please add those
information here?

>  * A new device flag, RTE_ETH_DEV_NOLIVE_MAC_ADDR, changes the order of
>    actions inside rte_eth_dev_start regarding MAC set. Some NICs do not
>    support MAC changes once the port has started and with this new device
>