On 12/16/24 21:58, Stephen Hemminger wrote:
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.
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.rybche...@oktetlabs.ru>
