Hi Divin, Please find my comments inline.
On 11/17/23 4:24 PM, Divin Raj wrote: > CAUTION: This message has originated from an External Source. Please use > proper judgment and caution when opening attachments, clicking links, or > responding to this email. > > > 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. This has been posted multiple times on mailing list, but really doesn't solve the problem. > 2. Permit the firmware creator to determine the most suitable value from > the resource table. This could be one of the solution, but if we can achieve dynamic allocation (below 3) we prefer that. > 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/ > We can use above patch to start with. I did not have chance to look at above yet, but we had discussed it before and seems like a good solution. > 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. When working with upstream list, could you try to remove above footer please ?
