From: "Coyle, David" <david.coyle@intel.com>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/3] net/iavf: fix segment fault in AVX512
Date: Mon, 15 Mar 2021 17:07:05 +0000 [thread overview]
Message-ID: <MN2PR11MB3550FA7C73CCA6C4CD1EB3BCE36C9@MN2PR11MB3550.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1615512417-17404-1-git-send-email-wenzhuo.lu@intel.com>
Hi Wenzhuo
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Wenzhuo Lu
> Sent: Friday, March 12, 2021 1:27 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>; stable@dpdk.org
> Subject: [dpdk-dev] [PATCH 1/3] net/iavf: fix segment fault in AVX512
>
> Fix segment fault when failing to get the memory from the pool.
>
> Fixes: 31737f2b66fb ("net/iavf: enable AVX512 for legacy Rx")
> Cc: stable@dpdk.org
>
> Reported-by: David Coyle <David.Coyle@intel.com>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> ---
> drivers/net/iavf/iavf_rxtx_vec_avx512.c | 130
> ++++++++++++++++++++++++++++++++
> 1 file changed, 130 insertions(+)
>
> diff --git a/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> index 5cb4c7c..6134520 100644
> --- a/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> +++ b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> @@ -25,6 +25,9 @@
>
> rxdp = rxq->rx_ring + rxq->rxrearm_start;
>
> + if (!cache)
> + goto normal;
[DC] In the Tx path, in iavf_tx_free_bufs_avx512(), it also checks for cache->len == 0
Not sure if the extra check is necessary though - I don't know if 'cache' can be valid pointer
but have a length of 0
if (!cache || cache->len == 0)
goto normal;
> +
> /* We need to pull 'n' more MBUFs into the software ring from
> mempool
> * We inline the mempool function here, so we can vectorize the
> copy
> * from the cache into the shadow ring.
> @@ -127,6 +130,133 @@
> cache->len -= IAVF_DESCS_PER_LOOP_AVX;
> }
>
> + goto done;
> +
> +normal:
> + /* Pull 'n' more MBUFs into the software ring */
> + if (rte_mempool_get_bulk(rxq->mp,
> + (void *)rxp,
> + IAVF_RXQ_REARM_THRESH) < 0) {
> + if (rxq->rxrearm_nb + IAVF_RXQ_REARM_THRESH >=
> + rxq->nb_rx_desc) {
> + __m128i dma_addr0;
> +
> + dma_addr0 = _mm_setzero_si128();
> + for (i = 0; i < IAVF_DESCS_PER_LOOP_AVX; i++) {
> + rxp[i] = &rxq->fake_mbuf;
> + _mm_store_si128((__m128i *)&rxdp[i].read,
> + dma_addr0);
> + }
> + }
> + rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed
> +=
> + IAVF_RXQ_REARM_THRESH;
> + return;
> + }
> +
> +#ifndef RTE_LIBRTE_IAVF_16BYTE_RX_DESC
> + struct rte_mbuf *mb0, *mb1;
> + __m128i dma_addr0, dma_addr1;
> + __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
> + RTE_PKTMBUF_HEADROOM);
> + /* Initialize the mbufs in vector, process 4 mbufs in one loop */
[DC] Comment above should say 2 mbufs I think
> + for (i = 0; i < IAVF_RXQ_REARM_THRESH; i += 2, rxp += 2) {
> + __m128i vaddr0, vaddr1;
> +
> + mb0 = rxp[0];
> + mb1 = rxp[1];
> +
> + /* load buf_addr(lo 64bit) and buf_physaddr(hi 64bit) */
> + RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, buf_iova) !=
> + offsetof(struct rte_mbuf, buf_addr) + 8);
> + vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr);
> + vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr);
> +
> + /* convert pa to dma_addr hdr/data */
> + dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
> + dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
> +
> + /* add headroom to pa values */
> + dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
> + dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
> +
> + /* flush desc with pa dma_addr */
> + _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
> + _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
> + }
[DC] Large blocks of the code above is the same as in avx2 file... any possibility to have a
common function or functions?
> +#else
> + struct rte_mbuf *mb0, *mb1, *mb2, *mb3;
> + struct rte_mbuf *mb4, *mb5, *mb6, *mb7;
> + __m512i dma_addr0_3, dma_addr4_7;
> + __m512i hdr_room =
> _mm512_set1_epi64(RTE_PKTMBUF_HEADROOM);
> + /* Initialize the mbufs in vector, process 4 mbufs in one loop */
[DC] Comment above should say 8 mbufs
> + for (i = 0; i < IAVF_RXQ_REARM_THRESH;
> + i += 8, rxp += 8, rxdp += 8) {
<snip>
> +
> + /**
> + * merge 0 & 1, by casting 0 to 256-bit and inserting 1
> + * into the high lanes. Similarly for 2 & 3
> + */
[DC] Comment above should say "Similarly for 2 & 3, 4 & 5, 6 & 7"
> + vaddr0_1 =
> +
> _mm256_inserti128_si256(_mm256_castsi128_si256(vaddr0),
> + vaddr1, 1);
> + vaddr2_3 =
> +
The patch fixes the seg fault, but note I have only tested the default
'#ifndef RTE_LIBRTE_IAVF_16BYTE_RX_DESC' path
Tested-by: David Coyle <david.coyle@intel.com>
next prev parent reply other threads:[~2021-03-15 17:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 1:26 Wenzhuo Lu
2021-03-15 17:07 ` Coyle, David [this message]
2021-03-26 1:52 ` Lu, Wenzhuo
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=MN2PR11MB3550FA7C73CCA6C4CD1EB3BCE36C9@MN2PR11MB3550.namprd11.prod.outlook.com \
--to=david.coyle@intel.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
--cc=wenzhuo.lu@intel.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;
as well as URLs for NNTP newsgroup(s).