Re: [dpdk-dev] [PATCH] doc: notice for changes in kni structures

[Hemant Agrawal <hemant.agrawal@nxp.com>]

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.agrawal@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?


>
> Thanks,
> ferruh
>