ST Restricted
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Saturday, May 20, 2023 1:00 AM To: Bill Mills bill.mills@linaro.org Cc: Shah, Tanmay tanmay.shah@amd.com; ed.mooring@gmail.com; tammy.leino@siemens.com; Arnaud POULIQUEN arnaud.pouliquen@st.com; openamp-rp@lists.openampproject.org Subject: Re: [RFC]: Variable RpMsg buffer size in Linux Kernel
On Thu, 18 May 2023 at 10:27, Bill Mills bill.mills@linaro.org wrote:
On 5/18/23 12:00 PM, Shah, Tanmay wrote:
Hi all,
As of now, rpmsg buffer size is decided by RPMSG_BUF_SIZE macro. This is fixed to 512 bytes.
If platform needs to send larger than 512 bytes of payload, then the payload needs to be split between multiple buffers.
Instead of that, it would be useful if platform can configure RPMSG_BUF_SIZE somehow.
There are multiple options to achieve this:
- Move RPMSG_BUF_SIZE to Kconfig -> The approach is not accepted as single kernel may not work for all platforms.
- Keep device-tree property that mentions rpmsg buffer size.
- Something in dts: “rpmsg-buf-size = <512>”
- This way one kernel can work for all the platforms. If property is not mentioned, then we fallback to default size of 512 bytes.
- Dynamic buffer allocation
- This effort was done previously. Please refer to following discussion from kernel and openamp library:
i.Openamp library: https://github.com/OpenAMP/open-amp/pull/155 https://github.com/OpenAMP/open-amp/pull/155
1. Conclusion:https://github.com/OpenAMP/open-amp/issues/322#issuecomment-
98657382
8 <https://github.com/OpenAMP/open-amp/issues/322#issuecomment-
9865738
28>
ii.Kernel: https://patchwork.kernel.org/project/linux-remoteproc/cover/15489492 80-31794-1-git-send-email-xiaoxiang@xiaomi.com/ https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949 280-31794-1-git-send-email-xiaoxiang@xiaomi.com/
Lore link to same: https://lore.kernel.org/lkml/20190605043452.GI22737@tuxbook-pro/T/
I saw nothing in this thread that I would call a rejection.
It made the size choice based on the virtio config space which could come from firmware resource table now or virtio device config space if using virtio-mmio etc.
Bjorn did point out that a system where each side allocated its own buffers of whatever size desired would be more flexible but:
- did not object to this step
- that would be a pretty big departure from what we have not and we
would still need to negotiate its use.
The biggest issues I saw with the patch series was the details of how it did the config. That could have been fixed with a bit more effort.
I would vote we just resurrect this patch set and clean it up rather than going down the DTS route.
I agree - I did not find anything controversial in that patchset either. We can start with that and later supplement with the DTS if needed.
Also in favor of this approach
Regards, Arnaud
Bill
2. As part of this, RPMSG_BUF_SIZE is configurable on library side, but not on kernel side.If it looks reasonable to go with approach 2 without side-effects, I can develop and send the patch.
Thanks,
Tanmay
-- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur