DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] doc: add deprecation notice for iavf devarg auto reconfig
@ 2026-07-15 10:59 Ciara Loftus
  2026-07-15 12:01 ` Bruce Richardson
  2026-07-15 12:20 ` [PATCH v2] " Ciara Loftus
  0 siblings, 2 replies; 6+ messages in thread
From: Ciara Loftus @ 2026-07-15 10:59 UTC (permalink / raw)
  To: dev; +Cc: Ciara Loftus

The `auto_reconfig` devarg in the iavf driver is enabled by default and the
case for ever disabling it is weak. When disabled, it means the user is
requesting the driver not to restore settings (unicast/multicast
promiscuous modes) when recovering from a reset. The use case where this
might be desired is during a VF initiated reset where the user initiates
the reset and wants the VF brought back up in an untouched state. That
scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
rather than relying on this devarg, so it should be safe to remove the
devarg.

Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
 doc/guides/rel_notes/deprecation.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f5c12cc747..b88774a3ae 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -159,3 +159,12 @@ Deprecation Notices
 * net/iavf: The dynamic mbuf field used to detect LLDP packets on the
   transmit path in the iavf PMD will be removed in a future release.
   After removal, only packet type-based detection will be supported.
+
+* net/iavf: The ``auto_reconfig`` devarg is deprecated and will be removed
+  in a future release. It allows disabling the automatic restoration of
+  device settings after a VF reset, but this is of questionable value
+  since most applications expect their settings to be preserved
+  transparently across a reset. The only use case for this devarg is
+  arguably a VF initiated reset; however this functionality could be
+  supported by extending the ``rte_pmd_iavf_reinit`` API instead of
+  relying on a devarg.
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] doc: add deprecation notice for iavf devarg auto reconfig
  2026-07-15 10:59 [PATCH] doc: add deprecation notice for iavf devarg auto reconfig Ciara Loftus
@ 2026-07-15 12:01 ` Bruce Richardson
  2026-07-15 12:20 ` [PATCH v2] " Ciara Loftus
  1 sibling, 0 replies; 6+ messages in thread
From: Bruce Richardson @ 2026-07-15 12:01 UTC (permalink / raw)
  To: Ciara Loftus; +Cc: dev

On Wed, Jul 15, 2026 at 10:59:59AM +0000, Ciara Loftus wrote:
> The `auto_reconfig` devarg in the iavf driver is enabled by default and the
> case for ever disabling it is weak. When disabled, it means the user is
> requesting the driver not to restore settings (unicast/multicast
> promiscuous modes) when recovering from a reset. The use case where this
> might be desired is during a VF initiated reset where the user initiates
> the reset and wants the VF brought back up in an untouched state. That
> scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
> rather than relying on this devarg, so it should be safe to remove the
> devarg.
> 
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index f5c12cc747..b88774a3ae 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -159,3 +159,12 @@ Deprecation Notices
>  * net/iavf: The dynamic mbuf field used to detect LLDP packets on the
>    transmit path in the iavf PMD will be removed in a future release.
>    After removal, only packet type-based detection will be supported.
> +
> +* net/iavf: The ``auto_reconfig`` devarg is deprecated and will be removed
> +  in a future release. It allows disabling the automatic restoration of
> +  device settings after a VF reset, but this is of questionable value
> +  since most applications expect their settings to be preserved
> +  transparently across a reset. The only use case for this devarg is
> +  arguably a VF initiated reset; however this functionality could be
> +  supported by extending the ``rte_pmd_iavf_reinit`` API instead of
> +  relying on a devarg.
> -- 

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

I think the text might be slightly too long for a deprecation notice, so
I'd tend toward removing the description of the possible API change, since
you only talk about how it "could" be done, rather than how it "will" be
done. The first two sentences should be enough on their own.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH v2] doc: add deprecation notice for iavf devarg auto reconfig
  2026-07-15 10:59 [PATCH] doc: add deprecation notice for iavf devarg auto reconfig Ciara Loftus
  2026-07-15 12:01 ` Bruce Richardson
@ 2026-07-15 12:20 ` Ciara Loftus
  2026-07-17  8:41   ` Medvedkin, Vladimir
  2026-07-17  8:46   ` David Marchand
  1 sibling, 2 replies; 6+ messages in thread
From: Ciara Loftus @ 2026-07-15 12:20 UTC (permalink / raw)
  To: dev; +Cc: Ciara Loftus, Bruce Richardson

The `auto_reconfig` devarg in the iavf driver is enabled by default and the
case for ever disabling it is weak. When disabled, it means the user is
requesting the driver not to restore settings (unicast/multicast
promiscuous modes) when recovering from a reset. The use case where this
might be desired is during a VF initiated reset where the user initiates
the reset and wants the VF brought back up in an untouched state. That
scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
rather than relying on this devarg, so it should be safe to remove the
devarg.

Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
v2:
* Shortened deprecation note
---
 doc/guides/rel_notes/deprecation.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f5c12cc747..910feb7cf2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -159,3 +159,9 @@ Deprecation Notices
 * net/iavf: The dynamic mbuf field used to detect LLDP packets on the
   transmit path in the iavf PMD will be removed in a future release.
   After removal, only packet type-based detection will be supported.
+
+* net/iavf: The ``auto_reconfig`` devarg is deprecated and will be removed
+  in a future release. It allows disabling the automatic restoration of
+  device settings after a VF reset, but this is of questionable value
+  since most applications expect their settings to be preserved
+  transparently across a reset.
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] doc: add deprecation notice for iavf devarg auto reconfig
  2026-07-15 12:20 ` [PATCH v2] " Ciara Loftus
@ 2026-07-17  8:41   ` Medvedkin, Vladimir
  2026-07-22 12:41     ` Thomas Monjalon
  2026-07-17  8:46   ` David Marchand
  1 sibling, 1 reply; 6+ messages in thread
From: Medvedkin, Vladimir @ 2026-07-17  8:41 UTC (permalink / raw)
  To: Ciara Loftus, dev; +Cc: Bruce Richardson

Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>

On 7/15/2026 1:20 PM, Ciara Loftus wrote:
> The `auto_reconfig` devarg in the iavf driver is enabled by default and the
> case for ever disabling it is weak. When disabled, it means the user is
> requesting the driver not to restore settings (unicast/multicast
> promiscuous modes) when recovering from a reset. The use case where this
> might be desired is during a VF initiated reset where the user initiates
> the reset and wants the VF brought back up in an untouched state. That
> scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
> rather than relying on this devarg, so it should be safe to remove the
> devarg.
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> v2:
> * Shortened deprecation note
> ---
>   doc/guides/rel_notes/deprecation.rst | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index f5c12cc747..910feb7cf2 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -159,3 +159,9 @@ Deprecation Notices
>   * net/iavf: The dynamic mbuf field used to detect LLDP packets on the
>     transmit path in the iavf PMD will be removed in a future release.
>     After removal, only packet type-based detection will be supported.
> +
> +* net/iavf: The ``auto_reconfig`` devarg is deprecated and will be removed
> +  in a future release. It allows disabling the automatic restoration of
> +  device settings after a VF reset, but this is of questionable value
> +  since most applications expect their settings to be preserved
> +  transparently across a reset.

-- 
Regards,
Vladimir


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] doc: add deprecation notice for iavf devarg auto reconfig
  2026-07-15 12:20 ` [PATCH v2] " Ciara Loftus
  2026-07-17  8:41   ` Medvedkin, Vladimir
@ 2026-07-17  8:46   ` David Marchand
  1 sibling, 0 replies; 6+ messages in thread
From: David Marchand @ 2026-07-17  8:46 UTC (permalink / raw)
  To: Ciara Loftus; +Cc: dev, Bruce Richardson

On Wed, 15 Jul 2026 at 14:21, Ciara Loftus <ciara.loftus@intel.com> wrote:
>
> The `auto_reconfig` devarg in the iavf driver is enabled by default and the
> case for ever disabling it is weak. When disabled, it means the user is
> requesting the driver not to restore settings (unicast/multicast
> promiscuous modes) when recovering from a reset. The use case where this
> might be desired is during a VF initiated reset where the user initiates
> the reset and wants the VF brought back up in an untouched state. That
> scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
> rather than relying on this devarg, so it should be safe to remove the
> devarg.
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Acked-by: David Marchand <david.marchand@redhat.com>


-- 
David Marchand


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] doc: add deprecation notice for iavf devarg auto reconfig
  2026-07-17  8:41   ` Medvedkin, Vladimir
@ 2026-07-22 12:41     ` Thomas Monjalon
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Monjalon @ 2026-07-22 12:41 UTC (permalink / raw)
  To: Ciara Loftus; +Cc: dev, Bruce Richardson, Medvedkin, Vladimir, David Marchand

> > The `auto_reconfig` devarg in the iavf driver is enabled by default and the
> > case for ever disabling it is weak. When disabled, it means the user is
> > requesting the driver not to restore settings (unicast/multicast
> > promiscuous modes) when recovering from a reset. The use case where this
> > might be desired is during a VF initiated reset where the user initiates
> > the reset and wants the VF brought back up in an untouched state. That
> > scenario can be facilitated by extending the `rte_pmd_iavf_reinit` API
> > rather than relying on this devarg, so it should be safe to remove the
> > devarg.
> >
> > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>

Applied, thanks.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-07-22 12:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-15 10:59 [PATCH] doc: add deprecation notice for iavf devarg auto reconfig Ciara Loftus
2026-07-15 12:01 ` Bruce Richardson
2026-07-15 12:20 ` [PATCH v2] " Ciara Loftus
2026-07-17  8:41   ` Medvedkin, Vladimir
2026-07-22 12:41     ` Thomas Monjalon
2026-07-17  8:46   ` David Marchand

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox