On 9/28/2018 12:05 AM, Dan Gora wrote: > On Thu, Sep 27, 2018 at 6:49 PM, Ferruh Yigit <ferruh.yi...@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. >
