On 11/24/23 17:45, Divin Raj wrote:
> Hi Arnaud,
> Please find my comments inline.
>
> On 11/20/23 10:14 AM, Arnaud POULIQUEN wrote:
>> Hi Divin,
>>
>> On 11/17/23 23:24, Divin Raj wrote:
>>> 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_r58myzcs7s7zgtn1qfo3mmb...@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/[email protected]/
>>> [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 ) | | |
>>> +-------------------------------+ +-------------------------------+
>>
>> Do you have a proposal for dynamic allocation?
>>
>> RPMSG is based on the virtio protocol. The virtio driver in the Linux kernel
>> is responsible for allocating buffers for the virtio device on the remote
>> processor.
>>
>> In the current implementation (static allocation) the Linux
>> kernel allocates predefined buffers for the remote processor.
>>
>> How would you manage the fact that the sender allocates its own buffers and
>> references
>> them in the vring descriptor? This would require each core to have
>> a dual role, right?
>> - a virtio driver role on its TX vring
>> - a virtio device role on its RX vring."
>>
> I'm unsure if a dual role is feasible under the Virtio specification.
At least, it does not seem to align with the philosophy of VirtIO.
> However, would it make sense to set the size of the outbuf based on the
> Maximum Transmission Unit (MTU) size that is supported? Additionally,
> the size of the inbuf could be set by the firmware, suggesting that it
> should be derived from the resource table. With this approach, I believe
> the sender can decide the maximum size.
It is not clear to me what your proposal is.
Are you speaking about a pre-allocated buffers as proposed in [1],
or are you speaking about dynamic allocation of the RPMsg in a pool?
Regards,
Arnaud
>
> Regards
> Divin
>
>>
>> Regards,
>> Arnaud
>>
>
>>
>>>
>>> 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.
>
> 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.
