All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Remi Pommarel <repk@triplefau.lt>
Cc: ath12k@lists.infradead.org,  Nicolas Escande <nico.escande@gmail.com>
Subject: Re: Allocating more RX descriptors that can fit in their related rings
Date: Thu, 05 Sep 2024 21:36:56 +0300	[thread overview]
Message-ID: <87zfomgd6f.fsf@kernel.org> (raw)
In-Reply-To: <ZtigjqSbAWZYU_KQ@pilgrim> (Remi Pommarel's message of "Wed, 4 Sep 2024 20:01:50 +0200")

Remi Pommarel <repk@triplefau.lt> writes:

> 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 ?

I don't know why it's so and no replies from others. I recommend just
sending a patch, preferably with numbers explaining how much memory is
saved, and let's see if anyone reacts.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


  reply	other threads:[~2024-09-05 18:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-04 18:01 Allocating more RX descriptors that can fit in their related rings Remi Pommarel
2024-09-05 18:36 ` Kalle Valo [this message]
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=87zfomgd6f.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath12k@lists.infradead.org \
    --cc=nico.escande@gmail.com \
    --cc=repk@triplefau.lt \
    /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.