From: Remi Pommarel <repk@triplefau.lt>
To: ath12k@lists.infradead.org
Cc: Nicolas Escande <nico.escande@gmail.com>
Subject: Allocating more RX descriptors that can fit in their related rings
Date: Wed, 4 Sep 2024 20:01:50 +0200 [thread overview]
Message-ID: <ZtigjqSbAWZYU_KQ@pilgrim> (raw)
Hello,
As far as I understand a bunch (ATH12K_RX_DESC_COUNT) of rx descriptors
gets allocated, then CMEM is configured for those descriptors cookie
conversion and is kept available in dp->rx_desc_free_list pool.
Those descriptors seem to be used to fed two different rings, the
rx_refill_buf_ring ring via ath12k_dp_rx_bufs_replenish() and the
reo_reinject_ring one with ath12k_dp_rx_h_defrag_reo_reinject(). While
the former is kept fully used if possible the latter is only used on
demand (i.e. reinjection of defragmented MPDU).
It seems that the number of RX descriptors ATH12K_RX_DESC_COUNT (12288)
is higher than what those two rings can fit (DP_REO_REINJECT_RING_SIZE +
DP_RXDMA_BUF_RING_SIZE = 4096 + 32 = 4128).
My question is why are we allocating that much (12288) buffer if only a
small part (4128) can be used in worst case ?
Wouldn't it be ok to only allocate just enough RX descriptors to fill
both ring (with proper 512 alignment to ease CMEM configuration) as
below ?
#define ATH12K_RX_DESC_COUNT ALIGN(DP_REO_REINJECT_RING_SIZE + \
DP_RXDMA_BUF_RING_SIZE, \
ATH12K_MAX_SPT_ENTRIES)
Or am I missing something and this is going to impact performances ?
Thanks
--
Remi
next reply other threads:[~2024-09-04 18:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 18:01 Remi Pommarel [this message]
2024-09-05 18:36 ` Allocating more RX descriptors that can fit in their related rings Kalle Valo
2024-09-06 3:57 ` Karthikeyan Periyasamy
2024-09-06 4:00 ` Karthikeyan Periyasamy
2024-09-06 16:09 ` Remi Pommarel
2024-09-07 2:39 ` Karthikeyan Periyasamy
2024-09-09 13:12 ` Remi Pommarel
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=ZtigjqSbAWZYU_KQ@pilgrim \
--to=repk@triplefau.lt \
--cc=ath12k@lists.infradead.org \
--cc=nico.escande@gmail.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.