On 5/3/2017 4:50 PM, Stephen Hemminger wrote: > On Wed, 3 May 2017 17:01:31 +0530 > Hemant Agrawal <hemant.agra...@nxp.com> wrote: > >> Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com> >> --- >> doc/guides/rel_notes/deprecation.rst | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index a3e7c72..0c1ef2c 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -81,3 +81,10 @@ Deprecation Notices >> >> - ``rte_crpytodev_scheduler_mode_get``, replaced by >> ``rte_cryptodev_scheduler_mode_get`` >> - ``rte_crpytodev_scheduler_mode_set``, replaced by >> ``rte_cryptodev_scheduler_mode_set`` >> + >> +* kni: additional functionality is planned to be added in kni to support >> mtu, macaddr, >> + gso_size, promiscusity configuration. >> + some of the kni structure will be changed to support additional >> functionality >> + e.g ``rte_kni_request`` to support promiscusity`` and mac_addr, >> + ``rte_kni_mbu`` to support the configured gso_size, >> + ``rte_kni_device_info`` and ``rte_kni_conf`` to also support mtu and >> macaddr. > > Why are these exposed as something applications should care about? > The data structures in rte_kni_common.h are not an API
+1, rte_kni_common.h is a contract between user - kernel space, not part of API.
