From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Wei Fang <wei.fang@nxp.com>
Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
"ast@kernel.org" <ast@kernel.org>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
"hawk@kernel.org" <hawk@kernel.org>,
"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"imx@lists.linux.dev" <imx@lists.linux.dev>
Subject: Re: [PATCH net 3/3] net: enetc: reset xdp_tx_in_flight when updating bpf program
Date: Fri, 27 Sep 2024 17:33:08 +0300 [thread overview]
Message-ID: <20240927143308.emkgu7x5ybjnqaty@skbuf> (raw)
In-Reply-To: <PAXPR04MB85105CC61372D1F2FC48C89A886F2@PAXPR04MB8510.eurprd04.prod.outlook.com>
Hi Wei,
On Mon, Sep 23, 2024 at 04:59:56AM +0300, Wei Fang wrote:
> Okay, I have tested this solution (see changes below), and from what I observed,
> the xdp_tx_in_flight can naturally drop to 0 in every test. So if there are no other
> risks, the next version will use this solution.
>
Sorry for the delay. I have tested this variant and it works. Just one
thing below.
> @@ -2467,10 +2469,6 @@ void enetc_start(struct net_device *ndev)
> struct enetc_ndev_priv *priv = netdev_priv(ndev);
> int i;
>
> - enetc_setup_interrupts(priv);
> -
> - enetc_enable_tx_bdrs(priv);
> -
> for (i = 0; i < priv->bdr_int_num; i++) {
> int irq = pci_irq_vector(priv->si->pdev,
> ENETC_BDR_INT_BASE_IDX + i);
> @@ -2479,6 +2477,10 @@ void enetc_start(struct net_device *ndev)
> enable_irq(irq);
> }
>
> + enetc_setup_interrupts(priv);
> +
> + enetc_enable_tx_bdrs(priv);
> +
> enetc_enable_rx_bdrs(priv);
>
> netif_tx_start_all_queues(ndev);
> @@ -2547,6 +2549,12 @@ void enetc_stop(struct net_device *ndev)
>
> enetc_disable_rx_bdrs(priv);
>
> + enetc_wait_bdrs(priv);
> +
> + enetc_disable_tx_bdrs(priv);
> +
> + enetc_clear_interrupts(priv);
Here, NAPI may still be scheduled. So if you clear interrupts, enetc_poll()
on another CPU might still have time to re-enable them. This makes the
call pointless.
Please move the enetc_clear_interrupts() call after the for() loop below
(AKA leave it where it is).
> +
> for (i = 0; i < priv->bdr_int_num; i++) {
> int irq = pci_irq_vector(priv->si->pdev,
> ENETC_BDR_INT_BASE_IDX + i);
> @@ -2555,12 +2563,6 @@ void enetc_stop(struct net_device *ndev)
> napi_synchronize(&priv->int_vector[i]->napi);
> napi_disable(&priv->int_vector[i]->napi);
> }
> -
> - enetc_wait_bdrs(priv);
> -
> - enetc_disable_tx_bdrs(priv);
> -
> - enetc_clear_interrupts(priv);
> }
> EXPORT_SYMBOL_GPL(enetc_stop);
FWIW, there are at least 2 other valid ways of solving this problem. One
has already been mentioned (reset the counter in enetc_free_rx_ring()):
@@ -2014,6 +2015,8 @@ static void enetc_free_rx_ring(struct enetc_bdr *rx_ring)
__free_page(rx_swbd->page);
rx_swbd->page = NULL;
}
+
+ rx_ring->xdp.xdp_tx_in_flight = 0;
}
static void enetc_free_rxtx_rings(struct enetc_ndev_priv *priv)
And the other would be to keep rescheduling NAPI until there are no more
pending XDP_TX frames.
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index 3cff76923ab9..36520f8c49a6 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1689,6 +1689,7 @@ static int enetc_poll(struct napi_struct *napi, int budget)
work_done = enetc_clean_rx_ring_xdp(rx_ring, napi, budget, prog);
else
work_done = enetc_clean_rx_ring(rx_ring, napi, budget);
- if (work_done == budget)
+ if (work_done == budget || rx_ring->xdp.xdp_tx_in_flight)
complete = false;
if (work_done)
But I like your second proposal the best. It doesn't involve adding an
unnecessary extra test in the fast path.
next prev parent reply other threads:[~2024-09-27 14:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 8:41 [PATCH net 0/3] net: enetc: fix some issues of XDP Wei Fang
2024-09-19 8:41 ` [PATCH net 1/3] net: enetc: remove xdp_drops statistic from enetc_xdp_drop() Wei Fang
2024-09-20 12:08 ` Maciej Fijalkowski
2024-09-23 5:02 ` Ratheesh Kannoth
2024-09-23 5:53 ` Wei Fang
2024-09-27 14:25 ` Vladimir Oltean
2024-09-19 8:41 ` [PATCH net 2/3] net: enetc: fix the issues of XDP_REDIRECT feature Wei Fang
2024-09-20 12:50 ` Maciej Fijalkowski
2024-09-27 14:41 ` Vladimir Oltean
2024-09-29 1:35 ` Wei Fang
2024-09-19 8:41 ` [PATCH net 3/3] net: enetc: reset xdp_tx_in_flight when updating bpf program Wei Fang
2024-09-19 13:21 ` Vladimir Oltean
2024-09-20 3:12 ` Wei Fang
2024-09-23 4:56 ` Ratheesh Kannoth
2024-09-23 5:48 ` Wei Fang
2024-09-20 13:04 ` Maciej Fijalkowski
2024-09-20 14:05 ` Wei Fang
2024-09-20 14:25 ` Vladimir Oltean
2024-09-20 14:29 ` Vladimir Oltean
2024-09-23 1:59 ` Wei Fang
2024-09-27 14:33 ` Vladimir Oltean [this message]
2024-09-29 1:31 ` Wei Fang
2024-09-27 14:38 ` Vladimir Oltean
-- strict thread matches above, loose matches on Subject: below --
2024-09-19 11:12 Subbaraya Sundeep
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=20240927143308.emkgu7x5ybjnqaty@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=claudiu.manoil@nxp.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=imx@lists.linux.dev \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=wei.fang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox