mbox series

[v1,0/6] ethdev: allow unknown link speed

Message ID 20200427095737.11082-1-i.dyukov@samsung.com (mailing list archive)
Headers
Series ethdev: allow unknown link speed |

Message

Ivan Dyukov April 27, 2020, 9:57 a.m. UTC
  This is initial patchset which introduces UNKNOWN speed to dpdk
applications. Also it contains changes related to printf formating.
Patchset contains changes for app/ and doc/ folders.
examples/ folder will be provided later.
  

Comments

Ferruh Yigit May 6, 2020, 5:42 p.m. UTC | #1
On 4/27/2020 10:57 AM, Ivan Dyukov wrote:
> This is initial patchset which introduces UNKNOWN speed to dpdk
> applications. Also it contains changes related to printf formating.
> Patchset contains changes for app/ and doc/ folders.
> examples/ folder will be provided later.
> 
> 

Also I can see there are some physical PMDs that are using 'ETH_SPEED_NUM_NONE'
as unknown, can we fix them as part of this set?
  
Ivan Dyukov May 7, 2020, 8:53 a.m. UTC | #2
06.05.2020 20:42, Ferruh Yigit пишет:
> On 4/27/2020 10:57 AM, Ivan Dyukov wrote:
>> This is initial patchset which introduces UNKNOWN speed to dpdk
>> applications. Also it contains changes related to printf formating.
>> Patchset contains changes for app/ and doc/ folders.
>> examples/ folder will be provided later.
>>
>>
> Also I can see there are some physical PMDs that are using 'ETH_SPEED_NUM_NONE'
> as unknown, can we fix them as part of this set?
>
Initially, we had a plan to use UNKNOWN only for virtual devices.

Thomas, could you please comment this?
  
Thomas Monjalon May 7, 2020, 10:31 a.m. UTC | #3
07/05/2020 10:53, Ivan Dyukov:
> 06.05.2020 20:42, Ferruh Yigit пишет:
> > On 4/27/2020 10:57 AM, Ivan Dyukov wrote:
> >> This is initial patchset which introduces UNKNOWN speed to dpdk
> >> applications. Also it contains changes related to printf formating.
> >> Patchset contains changes for app/ and doc/ folders.
> >> examples/ folder will be provided later.
> >>
> >>
> > Also I can see there are some physical PMDs that are using 'ETH_SPEED_NUM_NONE'
> > as unknown, can we fix them as part of this set?
> >
> Initially, we had a plan to use UNKNOWN only for virtual devices.
> 
> Thomas, could you please comment this?

No I think UNKNOWN must be used also for HW devices which are not able
to provide a speed value.

In mlx5 case, it can be used to return the link status (up/down)
even if speed query is failing (it happens with buggy kernel version).
  
Ivan Dyukov May 7, 2020, 1:55 p.m. UTC | #4
07.05.2020 13:31, Thomas Monjalon пишет:
> 07/05/2020 10:53, Ivan Dyukov:
>> 06.05.2020 20:42, Ferruh Yigit пишет:
>>> On 4/27/2020 10:57 AM, Ivan Dyukov wrote:
>>>> This is initial patchset which introduces UNKNOWN speed to dpdk
>>>> applications. Also it contains changes related to printf formating.
>>>> Patchset contains changes for app/ and doc/ folders.
>>>> examples/ folder will be provided later.
>>>>
>>>>
>>> Also I can see there are some physical PMDs that are using 'ETH_SPEED_NUM_NONE'
>>> as unknown, can we fix them as part of this set?
>>>
>> Initially, we had a plan to use UNKNOWN only for virtual devices.
>>
>> Thomas, could you please comment this?
> No I think UNKNOWN must be used also for HW devices which are not able
> to provide a speed value.
>
> In mlx5 case, it can be used to return the link status (up/down)
> even if speed query is failing (it happens with buggy kernel version).
>
Ok.  Is ETH_SPEED_NUM_NONE still needed then?  could it be replaced by 
UNKNOWN everywhere?
>
  
Ferruh Yigit May 7, 2020, 2:08 p.m. UTC | #5
On 5/7/2020 2:55 PM, Ivan Dyukov wrote:
> 07.05.2020 13:31, Thomas Monjalon пишет:
>> 07/05/2020 10:53, Ivan Dyukov:
>>> 06.05.2020 20:42, Ferruh Yigit пишет:
>>>> On 4/27/2020 10:57 AM, Ivan Dyukov wrote:
>>>>> This is initial patchset which introduces UNKNOWN speed to dpdk
>>>>> applications. Also it contains changes related to printf formating.
>>>>> Patchset contains changes for app/ and doc/ folders.
>>>>> examples/ folder will be provided later.
>>>>>
>>>>>
>>>> Also I can see there are some physical PMDs that are using 'ETH_SPEED_NUM_NONE'
>>>> as unknown, can we fix them as part of this set?
>>>>
>>> Initially, we had a plan to use UNKNOWN only for virtual devices.
>>>
>>> Thomas, could you please comment this?
>> No I think UNKNOWN must be used also for HW devices which are not able
>> to provide a speed value.
>>
>> In mlx5 case, it can be used to return the link status (up/down)
>> even if speed query is failing (it happens with buggy kernel version).
>>
> Ok.  Is ETH_SPEED_NUM_NONE still needed then?  could it be replaced by 
> UNKNOWN everywhere?

It is needed, please don't replace it.

For example when the link is down, device speed is 'ETH_SPEED_NUM_NONE', but
when the link is up but driver doesn't know the speed, for some reason, device
speed is 'ETH_SPEED_NUM_UNKNOWN'.

First patch says 'ETH_SPEED_NUM_UNKNOWN' is for two cases:
	- speed is not known by the driver
	- device is virtual

We are talking about first case above.