From: Divin Raj <divin.raj@arm.com>
To: linux-remoteproc@vger.kernel.org
Subject: [Discussion]: Enhance virtio rpmsg bus driver buffer allocation
Date: Fri, 17 Nov 2023 22:24:20 +0000 [thread overview]
Message-ID: <7eb830b3-e915-4151-ae10-46ce7cd68fa1@arm.com> (raw)
In-Reply-To: <1af16ff8-5706-45e5-9737-05da39957c95@arm.com>
On 10/23/23 11:44 AM, Divin Raj wrote:
> Hello all,
>
> I am reaching out with reference to the patch discussed here: Enhanced
> virtio rpmsg bus driver buffer allocation.
> <https://lore.kernel.org/all/CAH2Cfb-sv3SAL8bcczC-Dc3_r58MYZCS7s7zGtn1Qfo3mmBqVg@mail.gmail.com/>
>
> I've been keenly following the developments around enhancing buffer
> allocation strategies, especially those focused on dynamic buffer sizing
> and the considerations for systems under varying memory constraints.This
> work is highly relevant to several projects I am involved in, and I am
> quite interested in its progression. May I kindly request an update on
> the current phase of these initiatives? Additionally, I am eager to know
> if there would be an opportunity for me to contribute to enhancing the
> patch, possibly by working on improvements or assisting in verification
> processes.
>
> Furthermore, if there are any condensed resources, summaries, or
> specific threads that encapsulate recent advancements or discussions on
> this topic, I would be grateful to receive directions to them.
>
> I appreciate everyone's dedicated efforts and invaluable contributions
> to this area of development. Looking forward to the updates.
>
> Regards Divin
>
Hello Linux Community,
In one of our internal projects, we encountered a challenge with RPMSG
buffer allocation. Our goal is to optimize memory allocation for an
out-of-tree RPMSG Ethernet device driver using virtio. This is to ensure
support for packet sizes matching the standard MTU (Maximum Transmission
Unit) size of 1500 bytes.
To mitigate this issue, There are few possible solutions:
1. Configure buffer size and number through Kconfig.
2. Permit the firmware creator to determine the most suitable value from
the resource table.
3. Enable independent configurations on both ends. This approach would
support both dynamic and fixed buffer configurations using a generic
allocator.
Reference:
[1]:
https://lore.kernel.org/all/1548949280-31794-4-git-send-email-xiaoxiang@xiaomi.com/
[2]: https://lore.kernel.org/all/20190701061353.GE1263@builder/
Draft Design Overview:
Based on the reference patch and the discussions, we have outlined the
following key points for the belw design:
1. Assure compatibility, enabling both Linux and the remote system to
interchangeably transmit and receive messages, irrespective of size.
2. For systems with constrained shared memory:
Systems with small, shared memory, we need to deal with a
limited/optimized memory chunk. To avoid memory fragmentation, the
allocator should have a pre-reserved buffer pool
3. The implementation should ensure that the remote side does not
receive messages based on its allocation parameters.
do you think it could make sense?
High level view:
+------------------+ +------------------+
| | | |
| Linux | | Remote |
| | | |
| +----------+ | +-----------------+ | +----------+ |
| | RPMSG | | <---> | Buffer Allocator|<--->| | RPMSG | |
| +----------+ | | (Dynamic/Static)| | +----------+ |
| | +-----------------+ | |
+------------------+ +------------------+
Detailed view:
+-------------------------+
| Message Creation |
| (Both Linux/Remote) |
+------------+------------+
|
v
+-------------------------+
| Determine the allocation|
| strategy |
+------------+------------+
|
+--------------+--------------+
| |
+-------------------------------+ +-------------------------------+
| Dynamic allocation | | Static allocation |
| (Buffer allocator allocates | | (Pre-reserved memory |
| memory space as needed, | | space) |
| based on the current | | |
| message requirement ) | | |
+-------------------------------+ +-------------------------------+
We would greatly appreciate any feedback, suggestions, or improvements
you could provide.
Thank you for your time and consideration.
Regards
Divin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next parent reply other threads:[~2023-11-17 22:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1af16ff8-5706-45e5-9737-05da39957c95@arm.com>
2023-11-17 22:24 ` Divin Raj [this message]
2023-11-20 10:14 ` [Discussion]: Enhance virtio rpmsg bus driver buffer allocation Arnaud POULIQUEN
2023-11-24 16:45 ` Divin Raj
2023-11-28 8:34 ` Arnaud POULIQUEN
2023-11-28 11:19 ` Divin Raj
2023-11-28 13:45 ` Arnaud POULIQUEN
2023-12-07 12:47 ` Divin Raj
2024-01-11 17:33 ` Mathieu Poirier
2024-01-12 22:39 ` Mathieu Poirier
2023-11-21 5:54 ` Tanmay Shah
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=7eb830b3-e915-4151-ae10-46ce7cd68fa1@arm.com \
--to=divin.raj@arm.com \
--cc=linux-remoteproc@vger.kernel.org \
/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