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:

1. Move RPMSG_BUF_SIZE to Kconfig -> The approach is not accepted as single kernel may not work for all platforms.
2. Keep device-tree property that mentions rpmsg buffer size.
   1. Something in dts: “rpmsg-buf-size = <512>”
   2. This way one kernel can work for all the platforms. If property is not mentioned, then we fallback to default size of 512 bytes.
3. Dynamic buffer allocation
   1. 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-986573828 <https://github.com/OpenAMP/open-amp/issues/322#issuecomment-986573828>

ii.Kernel: https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949280-31794... https://patchwork.kernel.org/project/linux-remoteproc/cover/1548949280-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.

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