On 10/10/2018 4:01 PM, Dan Gora wrote: > On Wed, Oct 10, 2018 at 11:16 AM Ferruh Yigit <ferruh.yi...@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?
