[dpdk-dev] [PATCH v2 1/5] kni: add API to set link status on kernel interface

[Ferruh Yigit]

On 9/28/2018 12:05 AM, Dan Gora wrote:
> On Thu, Sep 27, 2018 at 6:49 PM, Ferruh Yigit <ferruh.yigit at intel.com> wrote:
>>>> It would be useful if it writes the values of virtual interface, but this API
>>>> prints user input.
>>>>
>>> I'm sorry, Ferruh, I really don't understand what you are referring to
>>> here.  What virtual interface are you talking about?
>>
>> Virtual interface is KNI interface, Linux virtual network interface.
>>
>>
>> Let me try again,
>>
>> You are adding a new API to KNI library, which is to set link status of KNI
>> interface.
>>
>> This API prints some link related values in its log. But these values are not
>> applied to KNI interface or not the values coming from KNI interface. These are
>> just values provided by user to the API, I am saying printing these values in
>> log can be confusing, the user may think API applies these values to KNI interface.
> 
> Well, yes the link_status (link up, link down) _is_ applied to the KNI
> interface.  When that occurs, most people want to know what the link
> speed is that the link came up at.  

+1 to this, people would like to know link speed of the interface.
Are you printing link speed of interface? You are printing whatever user pass to
API.
I guess you trust to user to provide correct values there, but since only link
up & down matters, what prevents user to leave other fields, like speed, just
random values?


> Again, this is how every other
> Ethernet driver in linux works.  I doubt that someone would be
> confused by that.
> 
> If the KNI interface is purely virtual (that is, it does not
> correspond to any physical Ethernet port), then the DPDK application
> writer is under no obligation to use this API function, or they can
> use it and just set the speed to 0.  If the end user understands that
> the KNI interface is purely virtual, then they should not be confused
> that the speed is 0 or that the duplex/autoNeg values are irrelevant.
> 
> I just don't see how this could cause any confusion.
>