On Sun, 15 Dec 2024 11:56:55 +0300
Andrew Rybchenko <andrew.rybche...@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.
>
> One nit below.
>
> Anyway:
> Acked-by: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
