[v3,0/6] kni: add API to set link status on kernel interface

  Hi All,

Attached is version 3 of a patchset to add a new API function to
set the link status on kernel interfaces created with the KNI kernel
module.

v3
====
* Use separate function to test rte_kni_update_link() in 'test' app.

* Separate changes to 'test' app into separate patch to facilitate
  possible merge with https://patches.dpdk.org/patch/44730/

* Remove changes to set KNI interfaces to 'up' in example/kni

> v2
> ====
> 
> * Fix bug where "Fixed" and "AutoNeg" were transposed in the link
>   status log message.
> 
> * Add rte_kni_update_link() to rte_kni_version.map
> 
> * Add rte_kni_update_link() tests to kni_autotest
> 
> * Update examples/kni to continuously monitor link status and
>   update the corresponding kernel interface with
>   rte_kni_update_link().
> 
> * Minor improvements to examples/kni: Add log message showing how
>   to show/zero stats.  Improve zeroing statistics.
> 
> Note that checkpatches.sh compains about patch 1/5, but this appears
> to be a bug with check-symbol-change or something.  If I move the
> fragment of the patch modifying rte_kni_version.map to the bottom of
> the patch file, it doesn't complain any more...  I just don't really
> have time to investigate this right now.
  
thanks
dan

Dan Gora (6):
  kni: add API to set link status on kernel interface
  kni: add link status test
  kni: set default carrier state to 'off'
  examples/kni: monitor and update link status continually
  examples/kni: add log msgs to show and clear stats
  examples/kni: improve zeroing statistics

 examples/kni/Makefile              |   2 +
 examples/kni/main.c                |  95 ++++++++++-----------
 kernel/linux/kni/kni_misc.c        |   2 +
 kernel/linux/kni/kni_net.c         |   2 +
 lib/librte_kni/rte_kni.c           |  57 +++++++++++++
 lib/librte_kni/rte_kni.h           |  18 ++++
 lib/librte_kni/rte_kni_version.map |   6 ++
 test/test/test_kni.c               | 131 +++++++++++++++++++++++++++++
 8 files changed, 264 insertions(+), 49 deletions(-)
  

On 9/27/2018 1:32 AM, Dan Gora wrote:
> Hi All,
> 
> Attached is version 3 of a patchset to add a new API function to
> set the link status on kernel interfaces created with the KNI kernel
> module.
> 
> v3
> ====
> * Use separate function to test rte_kni_update_link() in 'test' app.
> 
> * Separate changes to 'test' app into separate patch to facilitate
>   possible merge with https://patches.dpdk.org/patch/44730/
> 
> * Remove changes to set KNI interfaces to 'up' in example/kni
> 
>> v2
>> ====
>>
>> * Fix bug where "Fixed" and "AutoNeg" were transposed in the link
>>   status log message.
>>
>> * Add rte_kni_update_link() to rte_kni_version.map
>>
>> * Add rte_kni_update_link() tests to kni_autotest
>>
>> * Update examples/kni to continuously monitor link status and
>>   update the corresponding kernel interface with
>>   rte_kni_update_link().
>>
>> * Minor improvements to examples/kni: Add log message showing how
>>   to show/zero stats.  Improve zeroing statistics.
>>
>> Note that checkpatches.sh compains about patch 1/5, but this appears
>> to be a bug with check-symbol-change or something.  If I move the
>> fragment of the patch modifying rte_kni_version.map to the bottom of
>> the patch file, it doesn't complain any more...  I just don't really
>> have time to investigate this right now.
>   
> thanks
> dan
> 
> Dan Gora (6):
>   kni: add API to set link status on kernel interface
>   kni: add link status test
>   kni: set default carrier state to 'off'
>   examples/kni: monitor and update link status continually
>   examples/kni: add log msgs to show and clear stats
>   examples/kni: improve zeroing statistics

Hi Dan,

We are a little away to integration deadline, it is good to clarify the status
of the patchset.

There are a few change requests to this patchset:
1- 4/6, there is an open on adding command line option to control monitor/set
link status.
2- Dropping 6/6, I guess you already agreed on this.
3- 1/6, to have or not the log message.

I would like to see the patchset in the release, what do you think about above
actions?
  

On Wed, Oct 10, 2018 at 11:16 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 9/27/2018 1:32 AM, Dan Gora wrote:
> > Hi All,
> >
> > Attached is version 3 of a patchset to add a new API function to
> > set the link status on kernel interfaces created with the KNI kernel
> > module.
> >
> > v3
> > ====
> > * Use separate function to test rte_kni_update_link() in 'test' app.
> >
> > * Separate changes to 'test' app into separate patch to facilitate
> >   possible merge with https://patches.dpdk.org/patch/44730/
> >
> > * Remove changes to set KNI interfaces to 'up' in example/kni
> >
> >> v2
> >> ====
> >>
> >> * Fix bug where "Fixed" and "AutoNeg" were transposed in the link
> >>   status log message.
> >>
> >> * Add rte_kni_update_link() to rte_kni_version.map
> >>
> >> * Add rte_kni_update_link() tests to kni_autotest
> >>
> >> * Update examples/kni to continuously monitor link status and
> >>   update the corresponding kernel interface with
> >>   rte_kni_update_link().
> >>
> >> * Minor improvements to examples/kni: Add log message showing how
> >>   to show/zero stats.  Improve zeroing statistics.
> >>
> >> Note that checkpatches.sh compains about patch 1/5, but this appears
> >> to be a bug with check-symbol-change or something.  If I move the
> >> fragment of the patch modifying rte_kni_version.map to the bottom of
> >> the patch file, it doesn't complain any more...  I just don't really
> >> have time to investigate this right now.
> >
> > thanks
> > dan
> >
> > Dan Gora (6):
> >   kni: add API to set link status on kernel interface
> >   kni: add link status test
> >   kni: set default carrier state to 'off'
> >   examples/kni: monitor and update link status continually
> >   examples/kni: add log msgs to show and clear stats
> >   examples/kni: improve zeroing statistics
>
> Hi Dan,
>
> We are a little away to integration deadline, it is good to clarify the status
> of the patchset.
>
> There are a few change requests to this patchset:
> 1- 4/6, there is an open on adding command line option to control monitor/set
> link status.

No, I don't have any plans to add a command line option to do this.
Again, there is no reason for a command line option.

> 2- Dropping 6/6, I guess you already agreed on this.

No, I showed you that that patch to fix zeroing the statistics would
actually increase performance.  You just never responded to that
email.

> 3- 1/6, to have or not the log message.

I included a proposal in my last email.  Please take a look at that and respond.

> I would like to see the patchset in the release, what do you think about above
> actions?

I'm incredibly frustrated with this whole process to be honest...

d
  

On 10/10/2018 4:01 PM, Dan Gora wrote:
> On Wed, Oct 10, 2018 at 11:16 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>
>> On 9/27/2018 1:32 AM, Dan Gora wrote:
>>> Hi All,
>>>
>>> Attached is version 3 of a patchset to add a new API function to
>>> set the link status on kernel interfaces created with the KNI kernel
>>> module.
>>>
>>> v3
>>> ====
>>> * Use separate function to test rte_kni_update_link() in 'test' app.
>>>
>>> * Separate changes to 'test' app into separate patch to facilitate
>>>   possible merge with https://patches.dpdk.org/patch/44730/
>>>
>>> * Remove changes to set KNI interfaces to 'up' in example/kni
>>>
>>>> v2
>>>> ====
>>>>
>>>> * Fix bug where "Fixed" and "AutoNeg" were transposed in the link
>>>>   status log message.
>>>>
>>>> * Add rte_kni_update_link() to rte_kni_version.map
>>>>
>>>> * Add rte_kni_update_link() tests to kni_autotest
>>>>
>>>> * Update examples/kni to continuously monitor link status and
>>>>   update the corresponding kernel interface with
>>>>   rte_kni_update_link().
>>>>
>>>> * Minor improvements to examples/kni: Add log message showing how
>>>>   to show/zero stats.  Improve zeroing statistics.
>>>>
>>>> Note that checkpatches.sh compains about patch 1/5, but this appears
>>>> to be a bug with check-symbol-change or something.  If I move the
>>>> fragment of the patch modifying rte_kni_version.map to the bottom of
>>>> the patch file, it doesn't complain any more...  I just don't really
>>>> have time to investigate this right now.
>>>
>>> thanks
>>> dan
>>>
>>> Dan Gora (6):
>>>   kni: add API to set link status on kernel interface
>>>   kni: add link status test
>>>   kni: set default carrier state to 'off'
>>>   examples/kni: monitor and update link status continually
>>>   examples/kni: add log msgs to show and clear stats
>>>   examples/kni: improve zeroing statistics
>>
>> Hi Dan,
>>
>> We are a little away to integration deadline, it is good to clarify the status
>> of the patchset.
>>
>> There are a few change requests to this patchset:
>> 1- 4/6, there is an open on adding command line option to control monitor/set
>> link status.
> 
> No, I don't have any plans to add a command line option to do this.
> Again, there is no reason for a command line option.
> 
>> 2- Dropping 6/6, I guess you already agreed on this.
> 
> No, I showed you that that patch to fix zeroing the statistics would
> actually increase performance.  You just never responded to that
> email.
> 
>> 3- 1/6, to have or not the log message.
> 
> I included a proposal in my last email.  Please take a look at that and respond.
> 
>> I would like to see the patchset in the release, what do you think about above
>> actions?
> 
> I'm incredibly frustrated with this whole process to be honest...

Please don't be so, you are spending time/effort to improve an open source
project which is great, thank you again.

Why don't we take this as incremental steps, first get agreed part in a
patchset. 4/6 doesn't fit this but I can implement the command line part for you
if you agree, what do you think?
  

On Wed, Oct 10, 2018 at 8:00 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > I'm incredibly frustrated with this whole process to be honest...
>
> Please don't be so, you are spending time/effort to improve an open source
> project which is great, thank you again.
>
> Why don't we take this as incremental steps, first get agreed part in a
> patchset. 4/6 doesn't fit this but I can implement the command line part for you
> if you agree, what do you think?

I can work on it, but it might take a couple of days until I have
time.  What do you think about my proposal for
patch 1/4?  (see the end of 'Message-ID:
<CAGyogRZJmAWGXX0kXk+k69rbDbRqEJgS0H_Vw8h43-qFQ_ptEQ@mail.gmail.com>',
4 emails back in this thread..)

I can make it work without the log message in the API function, but I
need some way to get the previous status.  See my proposals in that
email above..

d