* [dpdk-stable] [PATCH] nfp: fix mbuf releasing when segments
@ 2017-04-26 10:27 Alejandro Lucero
2017-04-26 20:07 ` [dpdk-stable] [dpdk-dev] " Ferruh Yigit
0 siblings, 1 reply; 2+ messages in thread
From: Alejandro Lucero @ 2017-04-26 10:27 UTC (permalink / raw)
To: dev; +Cc: stable
If segments are used, just mbufs previously linked to head descriptor of
a mbuf chain are released. Other tx descriptor are used for the mbuf chain
but they keep their linked mbufs without releasing them. It is not a fatal
issue because sooner or later those descriptors will be head descriptors or
just used for a single mbuf packet, then those linked mbufs will be released.
However, this leads to apps needing bigger mbufs pools and some confusion
about memory requeriments. Indeed, because larget pools, some performance
impact could also be exptected due to cache misses.
With this patch all tx descriptors will release linked mbufs inside the
xmit function, and rte_pktmbuf_seg_free is used instead of rte_pktmbuf_free.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
---
drivers/net/nfp/nfp_net.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index eda87a5..5c5cba1 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2096,18 +2096,20 @@ uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
*/
pkt_size = pkt->pkt_len;
- /* Releasing mbuf which was prefetched above */
- if (*lmbuf)
- rte_pktmbuf_free(*lmbuf);
- /*
- * Linking mbuf with descriptor for being released
- * next time descriptor is used
- */
- *lmbuf = pkt;
-
while (pkt_size) {
/* Copying TSO, VLAN and cksum info */
*txds = txd;
+
+ /* Releasing mbuf used by this descriptor previously*/
+ if (*lmbuf)
+ rte_pktmbuf_free_seg(*lmbuf);
+
+ /*
+ * Linking mbuf with descriptor for being released
+ * next time descriptor is used
+ */
+ *lmbuf = pkt;
+
dma_size = pkt->data_len;
dma_addr = rte_mbuf_data_dma_addr(pkt);
PMD_TX_LOG(DEBUG, "Working with mbuf at dma address:"
@@ -2135,6 +2137,7 @@ uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
}
/* Referencing next free TX descriptor */
txds = &txq->txds[txq->wr_p];
+ lmbuf = &txq->txbufs[txq->wr_p].mbuf;
issued_descs++;
}
i++;
--
1.9.1
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [dpdk-stable] [dpdk-dev] [PATCH] nfp: fix mbuf releasing when segments
2017-04-26 10:27 [dpdk-stable] [PATCH] nfp: fix mbuf releasing when segments Alejandro Lucero
@ 2017-04-26 20:07 ` Ferruh Yigit
0 siblings, 0 replies; 2+ messages in thread
From: Ferruh Yigit @ 2017-04-26 20:07 UTC (permalink / raw)
To: Alejandro Lucero, dev; +Cc: stable
On 4/26/2017 11:27 AM, Alejandro Lucero wrote:
> If segments are used, just mbufs previously linked to head descriptor of
> a mbuf chain are released. Other tx descriptor are used for the mbuf chain
> but they keep their linked mbufs without releasing them. It is not a fatal
> issue because sooner or later those descriptors will be head descriptors or
> just used for a single mbuf packet, then those linked mbufs will be released.
> However, this leads to apps needing bigger mbufs pools and some confusion
> about memory requeriments. Indeed, because larget pools, some performance
> impact could also be exptected due to cache misses.
>
> With this patch all tx descriptors will release linked mbufs inside the
> xmit function, and rte_pktmbuf_seg_free is used instead of rte_pktmbuf_free.
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Applied to dpdk-next-net/master, thanks.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-04-26 20:07 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-26 10:27 [dpdk-stable] [PATCH] nfp: fix mbuf releasing when segments Alejandro Lucero
2017-04-26 20:07 ` [dpdk-stable] [dpdk-dev] " 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).