All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Po Liu <po.liu@nxp.com>
Cc: "Claudiu Manoil" <claudiu.manoil@nxp.com>,
	"Alex Marginean" <alexandru.marginean@nxp.com>,
	"Yangbo Lu" <yangbo.lu@nxp.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Vladimir Oltean" <vladimir.oltean@nxp.com>
Subject: [PATCH net-next 10/10] net: enetc: apply the MDIO workaround for XDP_REDIRECT too
Date: Sat, 17 Apr 2021 00:22:25 +0300	[thread overview]
Message-ID: <20210416212225.3576792-11-olteanv@gmail.com> (raw)
In-Reply-To: <20210416212225.3576792-1-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean@nxp.com>

Described in fd5736bf9f23 ("enetc: Workaround for MDIO register access
issue") is a workaround for a hardware bug that requires a register
access of the MDIO controller to never happen concurrently with a
register access of a port PF. To avoid that, a mutual exclusion scheme
with rwlocks was implemented - the port PF accessors are the 'read'
side, and the MDIO accessors are the 'write' side.

When we do XDP_REDIRECT between two ENETC interfaces, all is fine
because the MDIO lock is already taken from the NAPI poll loop.

But when the ingress interface is not ENETC, just the egress is, the
MDIO lock is not taken, so we might access the port PF registers
concurrently with MDIO, which will make the link flap due to wrong
values returned from the PHY.

To avoid this, let's just slap an enetc_lock_mdio/enetc_unlock_mdio at
the beginning and ending of enetc_xdp_xmit. The fact that the MDIO lock
is designed as a rwlock is important here, because the read side is
reentrant (that is one of the main reasons why we chose it). Usually,
the way we benefit of its reentrancy is by running the data path
concurrently on both CPUs, but in this case, we benefit from the
reentrancy by taking the lock even when the lock is already taken
(and that's the situation where ENETC is both the ingress and the egress
interface for XDP_REDIRECT, which was fine before and still is fine now).

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/ethernet/freescale/enetc/enetc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index f0ba612d5ce3..4f23829e7317 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1081,6 +1081,8 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
 	int xdp_tx_bd_cnt, i, k;
 	int xdp_tx_frm_cnt = 0;
 
+	enetc_lock_mdio();
+
 	tx_ring = priv->xdp_tx_ring[smp_processor_id()];
 
 	prefetchw(ENETC_TXBD(*tx_ring, tx_ring->next_to_use));
@@ -1109,6 +1111,8 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
 
 	tx_ring->stats.xdp_tx += xdp_tx_frm_cnt;
 
+	enetc_unlock_mdio();
+
 	return xdp_tx_frm_cnt;
 }
 
-- 
2.25.1


  parent reply	other threads:[~2021-04-16 21:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 21:22 [PATCH net-next 00/10] Fixups for XDP on NXP ENETC Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 01/10] net: enetc: remove redundant clearing of skb/xdp_frame pointer in TX conf path Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 02/10] net: enetc: rename the buffer reuse helpers Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 03/10] net: enetc: recycle buffers for frames with RX errors Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 04/10] net: enetc: stop XDP NAPI processing when build_skb() fails Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 05/10] net: enetc: remove unneeded xdp_do_flush_map() Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 06/10] net: enetc: increase TX ring size Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 07/10] net: enetc: use dedicated TX rings for XDP Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 08/10] net: enetc: handle the invalid XDP action the same way as XDP_DROP Vladimir Oltean
2021-04-16 21:22 ` [PATCH net-next 09/10] net: enetc: fix buffer leaks with XDP_TX enqueue rejections Vladimir Oltean
2021-04-16 21:22 ` Vladimir Oltean [this message]
2021-04-17  0:20 ` [PATCH net-next 00/10] Fixups for XDP on NXP ENETC 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=20210416212225.3576792-11-olteanv@gmail.com \
    --to=olteanv@gmail.com \
    --cc=alexandru.marginean@nxp.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=po.liu@nxp.com \
    --cc=toke@redhat.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=yangbo.lu@nxp.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.