* [PATCH] net/gve: always attempt Rx refill on DQ
@ 2024-10-01 23:45 Joshua Washington
2024-10-04 4:47 ` Ferruh Yigit
0 siblings, 1 reply; 2+ messages in thread
From: Joshua Washington @ 2024-10-01 23:45 UTC (permalink / raw)
To: Thomas Monjalon, Jeroen de Borst, Rushil Gupta,
Joshua Washington, Junfeng Guo
Cc: dev, stable, Ferruh Yigit, Praveen Kaligineedi
Before this patch, gve_rx_refill_dqo() is only called if the number of
packets received in a cycle is non-zero. However, in a
memory-constrained scenario, this doesn't behave well, as this could be
a potential source of lockup, if there is no memory and all buffers have
been received before memory is freed up for the driver to use.
This patch moves the gve_rx_refill_dqo() call to occur regardless of
whether packets have been received so that in the case that enough
memory is freed, the driver can recover.
Fixes: 45da16b5b181 ("net/gve: support basic Rx data path for DQO")
Cc: stable@dpdk.org
Signed-off-by: Joshua Washington <joshwash@google.com>
Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
Reviewed-by: Rushil Gupta <rushilg@google.com>
---
.mailmap | 1 +
drivers/net/gve/gve_rx_dqo.c | 6 ++----
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/.mailmap b/.mailmap
index d798a3f30f..d2f30cf8eb 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1174,6 +1174,7 @@ Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Prashant Upadhyaya <prashant.upadhyaya@aricent.com> <praupadhyaya@gmail.com>
Prateek Agarwal <prateekag@cse.iitb.ac.in>
Prathisna Padmasanan <prathisna.padmasanan@intel.com>
+Praveen Kaligineedi <pkaligineedi@google.com>
Praveen Shetty <praveen.shetty@intel.com>
Pravin Pathak <pravin.pathak@intel.com>
Prince Takkar <ptakkar@marvell.com>
diff --git a/drivers/net/gve/gve_rx_dqo.c b/drivers/net/gve/gve_rx_dqo.c
index d8e9eee4a8..60702d4100 100644
--- a/drivers/net/gve/gve_rx_dqo.c
+++ b/drivers/net/gve/gve_rx_dqo.c
@@ -195,14 +195,12 @@ gve_rx_burst_dqo(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
if (nb_rx > 0) {
rxq->rx_tail = rx_id;
- if (rx_id_bufq != rxq->next_avail)
- rxq->next_avail = rx_id_bufq;
-
- gve_rx_refill_dqo(rxq);
+ rxq->next_avail = rx_id_bufq;
rxq->stats.packets += nb_rx;
rxq->stats.bytes += bytes;
}
+ gve_rx_refill_dqo(rxq);
return nb_rx;
}
--
2.46.1.824.gd892dcdcdd-goog
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] net/gve: always attempt Rx refill on DQ
2024-10-01 23:45 [PATCH] net/gve: always attempt Rx refill on DQ Joshua Washington
@ 2024-10-04 4:47 ` Ferruh Yigit
0 siblings, 0 replies; 2+ messages in thread
From: Ferruh Yigit @ 2024-10-04 4:47 UTC (permalink / raw)
To: Joshua Washington, Thomas Monjalon, Jeroen de Borst,
Rushil Gupta, Junfeng Guo
Cc: dev, stable, Praveen Kaligineedi
On 10/2/2024 12:45 AM, Joshua Washington wrote:
> Before this patch, gve_rx_refill_dqo() is only called if the number of
> packets received in a cycle is non-zero. However, in a
> memory-constrained scenario, this doesn't behave well, as this could be
> a potential source of lockup, if there is no memory and all buffers have
> been received before memory is freed up for the driver to use.
>
> This patch moves the gve_rx_refill_dqo() call to occur regardless of
> whether packets have been received so that in the case that enough
> memory is freed, the driver can recover.
>
> Fixes: 45da16b5b181 ("net/gve: support basic Rx data path for DQO")
> Cc: stable@dpdk.org
>
> Signed-off-by: Joshua Washington <joshwash@google.com>
> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
> Reviewed-by: Rushil Gupta <rushilg@google.com>
>
Applied to dpdk-next-net/main, thanks.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-10-04 4:47 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-10-01 23:45 [PATCH] net/gve: always attempt Rx refill on DQ Joshua Washington
2024-10-04 4:47 ` Ferruh Yigit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).