On 5/8/2017 10:46 AM, Hemant Agrawal wrote: > On 5/4/2017 10:20 PM, Ferruh Yigit wrote: >> On 5/3/2017 12:31 PM, Hemant Agrawal 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_request is between KNI library and KNI kernel module, shouldn't >> be part of API. >> >>> + ``rte_kni_mbu`` to support the configured gso_size, >> >> Again, rte_kni_mbuf should be only concern of KNI kernel module. >> >>> + ``rte_kni_device_info`` and ``rte_kni_conf`` to also support mtu and >>> macaddr. >> >> rte_kni_device_info also between KNI library and KNI kernel module. >> >> I think deprecation notice not required for above ones. >> >> But you KNI patchset updates rte_kni_conf and rte_kni_ops. >> These are part of KNI API and changing them cause ABI breakage, >> but if new fields appended in these structs, this will not cause an ABI >> breakage, and I think that is better to do instead of deprecation >> notice, what do you think? > > I agree. >> >> >> And apart from above ABI issues, >> adding new fields to "rte_kni_ops" means DPDK application that use KNI >> should implement them, right? > > Well, it depend, if the application is interested in this information or > not? > >> So this suggest everyone require to set promiscuity of KNI device should >> implement this. > > yes! > >> Can't we find another way that all can benefit from a common implementation? > > how you want it differently? Any ideas?
Can having default implementations in librte_kni work? Would applications be doing something different, lets say to set MTU? > > >> >> Thanks, >> ferruh >> > >
