[PATCH v2 1/5] ethdev: check that device supports deferred start

[Andrew Rybchenko]

On 12/16/24 21:58, Stephen Hemminger wrote:
> On Sun, 15 Dec 2024 11:56:55 +0300
> Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru> wrote:
> 
>> On 12/14/24 21:07, Stephen Hemminger wrote:
>>> The check for supporting deferred start should be handled at
>>> the ethdev level for all devices.
>>
>> It is a good idea to check it on ethdev level.
>>
>> Strictly speaking presence of queue start/stop callback does not mean
>> support for deferred start right now. It is possible to use stop/start
>> without deferred start feature.
> 
> Right, there are drivers that define the callback but have no logic
> in place to do deferred start. They just ignore the flag.
> Drivers with this odditiy are:
> 	ark, atlantic, cxgbe, enic, hinic, ipn3ke, nfb, nfp, ntnic
> This patch set won't change that.
> 
> There are also some drivers which claim to support queue start/stop
> in the documentation, but there is no functions:
>     virtio, mana, netvsc, mlx4, vmxnet3
> Will fix that in next version of this series.
> 
>>
>> However, such check is much better than nothing since deferred start
>> definitely requires queue start callback.
>>
>> It would be good to clarify it in the documentation.
>> doc/guides/nics/features.rst does not mention deferred start at all.
>> In fact, I don't mind to couple deferred start to queue start/stop
>> features.
> 
> It is a bug that the drivers that do queue start/stop and don't
> implement deferred start. There is no hardware reason to not support
> it, just missing feature during driver development.

I agree. Please, don't forget to add rx_deferred_start and
tx_deferred_start to queue start/stop features in
doc/guides/nics/features.rst.

>>
>> One nit below.
>>
>> Anyway:
>> Acked-by: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>