From: Jakub Kicinski <kuba@kernel.org>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Mohammad Heib <mheib@redhat.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
Rafal Romanowski <rafal.romanowski@intel.com>
Subject: Re: [PATCH net-next v2 02/14] i40e: support generic devlink param "max_mac_per_vf"
Date: Mon, 20 Oct 2025 18:25:15 -0700 [thread overview]
Message-ID: <20251020182515.457ad11c@kernel.org> (raw)
In-Reply-To: <20251016-jk-iwl-next-2025-10-15-v2-2-ff3a390d9fc6@intel.com>
On Thu, 16 Oct 2025 23:08:31 -0700 Jacob Keller wrote:
> - The configured value is a theoretical maximum. Hardware limits may
> still prevent additional MAC addresses from being added, even if the
> parameter allows it.
Is "administrative policy" better than "theoretical max" ?
Also -- should we be scanning the existing state to check if some VM
hasn't violated the new setting and error or at least return a extack
to the user to warn that the policy is not currently adhered to?
next prev parent reply other threads:[~2025-10-21 1:25 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 6:08 [PATCH net-next v2 00/14] Intel Wired LAN Driver Updates 2025-10-15 (ice, iavf, ixgbe, i40e, e1000e) Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 01/14] devlink: Add new "max_mac_per_vf" generic device param Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 02/14] i40e: support generic devlink param "max_mac_per_vf" Jacob Keller
2025-10-21 1:25 ` Jakub Kicinski [this message]
2025-10-21 20:39 ` Jacob Keller
2025-10-21 23:07 ` Jakub Kicinski
2025-10-22 9:39 ` mohammad heib
2025-10-22 22:11 ` Jacob Keller
2025-10-24 8:07 ` mohammad heib
2025-10-17 6:08 ` [PATCH net-next v2 03/14] ice: add flow parsing for GTP and new protocol field support Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 04/14] ice: add virtchnl and VF context support for GTP RSS Jacob Keller
2025-10-21 1:22 ` Jakub Kicinski
2025-10-22 9:58 ` Loktionov, Aleksandr
2025-10-17 6:08 ` [PATCH net-next v2 05/14] ice: improve TCAM priority handling for RSS profiles Jacob Keller
2025-10-21 1:16 ` Jakub Kicinski
2025-10-21 20:41 ` Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 06/14] ice: Extend PTYPE bitmap coverage for GTP encapsulated flows Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 07/14] iavf: add RSS support for GTP protocol via ethtool Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 08/14] net: docs: add missing features that can have stats Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 09/14] ice: implement ethtool standard stats Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 10/14] ice: add tracking of good transmit timestamps Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 11/14] ice: implement transmit hardware timestamp statistics Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 12/14] ice: refactor to use helpers Jacob Keller
2025-10-17 6:08 ` [PATCH net-next v2 13/14] ixgbe: preserve RSS indirection table across admin down/up Jacob Keller
2025-10-21 1:32 ` Jakub Kicinski
2025-10-21 3:59 ` Kohei Enju
2025-10-21 23:10 ` Jakub Kicinski
2025-10-22 3:40 ` Kohei Enju
2025-10-23 0:26 ` Jakub Kicinski
2025-10-23 16:26 ` Kohei Enju
2025-10-17 6:08 ` [PATCH net-next v2 14/14] e1000e: Introduce private flag to disable K1 Jacob Keller
2025-10-21 1:33 ` [PATCH net-next v2 00/14] Intel Wired LAN Driver Updates 2025-10-15 (ice, iavf, ixgbe, i40e, e1000e) Jakub Kicinski
2025-10-21 1:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251020182515.457ad11c@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mheib@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=rafal.romanowski@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.