All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: "Jagielski, Jedrzej" <jedrzej.jagielski@intel.com>
Cc: Simon Horman <horms@kernel.org>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v1 5/6] ixgbe: E610: add MAC address runtime refresh
Date: Fri, 10 Jul 2026 11:57:50 +0200	[thread overview]
Message-ID: <alDCHrOYHvS1EdHE@boxer> (raw)
In-Reply-To: <PH0PR11MB59029D8B78557F03143546D3F0FE2@PH0PR11MB5902.namprd11.prod.outlook.com>

On Thu, Jul 09, 2026 at 09:37:27AM +0000, Jagielski, Jedrzej wrote:
> From: Simon Horman <horms@kernel.org> 
> Sent: Wednesday, July 8, 2026 7:02 PM
> 
> >This is an AI-generated review of your patch. The human sending this
> >email has considered the AI review valid, or at least plausible.
> >Full review at: https://netdev-ai.bots.linux.dev/sashiko/
> >---
> >ixgbe: E610: add MAC address runtime refresh
> >
> >This change polls RAR0 each service-task cycle on E610 and updates
> >netdev->dev_addr, hw->mac.addr and mac_table[0].addr when firmware has
> >altered the MAC.  A refresh is also invoked from ixgbe_reset() so the
> >address survives RAR0 clearing during init_hw().

[...]

> >[Medium]
> >Would it make sense to hoist the E610 gating out of
> >ixgbe_mac_addr_refresh() and skip the rtnl_lock()/rtnl_unlock()
> >entirely for non-E610 devices?
> >
> >The type check lives inside the helper:
> >
> >    static void ixgbe_mac_addr_refresh(struct ixgbe_adapter *adapter)
> >    {
> >        ...
> >        if (hw->mac.type != ixgbe_mac_e610)
> >            return;
> >        ...
> >    }
> >
> >so 82598, 82599, X540 and X550 adapters (which comprise most of the
> >ixgbe device family) acquire the global rtnl_mutex every service-task
> >cycle only to return immediately.  Something like:
> >
> >    if (adapter->hw.mac.type == ixgbe_mac_e610) {
> >        rtnl_lock();
> >        ixgbe_mac_addr_refresh(adapter);
> >        rtnl_unlock();
> >    }
> 
> Cannot introduce rtnl locking into ixgbe_mac_addr_refresh() as this
> can be already called within rtnl-locked path

i40e does a lot of dancing for cases like this. rtnl lock is handled via
boolean provided as function arg:

static void i40e_rebuild(struct i40e_pf *pf, bool reinit, bool lock_acquired)
...
	/* Release the RTNL lock before we start resetting VFs */
	if (!lock_acquired)
		rtnl_unlock();

...

end_unlock:
	if (!lock_acquired)
		rtnl_unlock();
> 
> >
> >would avoid the rtnl_mutex contention on non-E610 hardware.
> >
> >>  	ixgbe_reset_subtask(adapter);
> >>  	ixgbe_phy_interrupt_subtask(adapter);
> >>  	ixgbe_sfp_detection_subtask(adapter);

  reply	other threads:[~2026-07-10  9:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02  9:15 [PATCH iwl-next v1 0/6] ixgbe: improve FW/SW data synchronization Jedrzej Jagielski
2026-07-02  9:15 ` [Intel-wired-lan] " Jedrzej Jagielski
2026-07-02  9:15 ` [PATCH iwl-next v1 1/6] ixgbe: E610: init Link Status Events mask just once Jedrzej Jagielski
2026-07-02  9:15   ` [Intel-wired-lan] " Jedrzej Jagielski
2026-07-02  9:15 ` [PATCH iwl-next v1 2/6] ixgbe: E610: prevent from disabling LSE Jedrzej Jagielski
2026-07-02  9:15   ` [Intel-wired-lan] " Jedrzej Jagielski
2026-07-02  9:15 ` [PATCH iwl-next v1 3/6] ixgbe: E610: do not disable LSE on driver down/remove Jedrzej Jagielski
2026-07-02  9:15   ` [Intel-wired-lan] " Jedrzej Jagielski
2026-07-08 17:01   ` Simon Horman
2026-07-08 17:01     ` [Intel-wired-lan] " Simon Horman
2026-07-09  9:36     ` Jagielski, Jedrzej
2026-07-09  9:36       ` Jagielski, Jedrzej
2026-07-02  9:15 ` [PATCH iwl-next v1 4/6] ixgbe: E610: re-enable LSE unconditionally Jedrzej Jagielski
2026-07-02  9:15   ` [Intel-wired-lan] " Jedrzej Jagielski
2026-07-02  9:15 ` [PATCH iwl-next v1 5/6] ixgbe: E610: add MAC address runtime refresh Jedrzej Jagielski
2026-07-02  9:15   ` [Intel-wired-lan] " Jedrzej Jagielski
2026-07-07 13:34   ` Loktionov, Aleksandr
2026-07-07 13:34     ` Loktionov, Aleksandr
2026-07-08 17:02   ` Simon Horman
2026-07-09  9:37     ` Jagielski, Jedrzej
2026-07-09  9:37       ` Jagielski, Jedrzej
2026-07-10  9:57       ` Maciej Fijalkowski [this message]
2026-07-10 11:59         ` Jagielski, Jedrzej
2026-07-10 11:59           ` Jagielski, Jedrzej
2026-07-02  9:15 ` [PATCH iwl-next v1 6/6] ixgbe: take rtnl lock before ixgbe_reset() is called Jedrzej Jagielski
2026-07-02  9:15   ` [Intel-wired-lan] " Jedrzej Jagielski
2026-07-07 13:35   ` Loktionov, Aleksandr
2026-07-07 13:35     ` Loktionov, Aleksandr
2026-07-08 17:02   ` Simon Horman
2026-07-08 17:02     ` Simon Horman
2026-07-09  9:38     ` [Intel-wired-lan] " Jagielski, Jedrzej
2026-07-09  9:38       ` Jagielski, Jedrzej

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=alDCHrOYHvS1EdHE@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=horms@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jedrzej.jagielski@intel.com \
    --cc=netdev@vger.kernel.org \
    /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.