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

Ferruh Yigit ferruh.yigit at intel.com
Thu Sep 27 23:49:38 CEST 2018


On 9/27/2018 4:40 PM, Dan Gora wrote:
> On Thu, Sep 27, 2018 at 8:35 AM Ferruh Yigit <ferruh.yigit at intel.com> wrote:
>>
>> On 9/26/2018 7:56 PM, Dan Gora wrote:
>>> On Wed, Sep 26, 2018 at 1:42 PM, Ferruh Yigit <ferruh.yigit at intel.com> wrote:
>>>>> There is nothing to "reflect" to the kernel interface, nor to apply to
>>>>> the kernel interface.  This is exactly how every other kernel driver
>>>>> works on link status changes.  There is no "netif_set_speed()'
>>>>> function.  When a link status change occurs the kernel driver calls
>>>>> netif_carrier_on/off() and prints a message like this one.
>>>>
>>>> I am not suggesting reflecting these into interface, I am just saying why do you
>>>> print them?
>>>
>>> Because the information is useful and because every other Ethernet
>>> driver does the same thing when the link status changes.
>>
>> 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.


> 
>> The virtual interface may have different value, this API doesn't change anything
>> related other than link status, so why print user provided value.
> 
> Again, because all this information is useful if the KNI interface is
> reflecting the state of a real physical ethenet interface.  If the KNI
> interface is not reflecting a real peice of hardware, the user can
> continue not using this new API function or do something like set the
> speed to 0.  This is what we get from ENA PMD drivers on amazon for
> instance.  It's perfectly reasonable.
> 
>>
>> Won't you think it will be confusing if the virtual interface values are
>> different than what printed.
> 
> If what values are different from what?  I'm really confused as to
> what use case you are referring to here.  Can you give a concrete
> example?
> 
>> Or won't user will think API changed those values to printed one in interface?
> 
> again, what values?  Changed how?
> 



More information about the dev mailing list