RPMsg Extension layer including zero-copy

[Marek Novak]

Hello dear community, Hello Wendy,

Please find attached a patch implementing the zero-copy for RPMsg.
I have blindly ported the zero copy from an older version of RPMsg OpenAMP, which was used internally here in NXP, to use libmetal API.
I hope it should be ok. I could not run it on a real hardware, since we currently use internally for our microcontroller targets the RPMsg Lite.

The patch is generated against current head of openamp-libmetal branch (SHA1: 536f103ee4f7d4).

Please feel free to comment on the patch and to suggest any improvements!

Have a nice day,
Marek NOVAK

NXP Semiconductors

PS & BTW:

Do you think we could publish our RPMsg Lite implementation targeting mainly platforms, which are low on resources in let’s say: https://github.com/OpenAMP/RPMsg-Lite  ?

I think Petr Lukas has sent you recently some information about it.

[Jiaying Liang]

Thanks Marek,

Wendy

--
You received this message because you are subscribed to the Google Groups "open-amp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-amp+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

[Jiaying Liang]

HI Marek, Petr,

Here is my understanding of the patch:
* The tx send controls whether the it is zero copy by setting the RPMSG_BUF_HELD flag.
* The rx side, if the flag is set, it will not return the buffer in the rx callback.
* Either rx or tx side need to call rpmsg_release_rx_buffer() to release the buffer.

Is my understanding correct?

* When working with current Linux kernel, we cannot use this feature, is it correct? Do you have any plan for Linux kernel rpmsg upstream support?
* Tx side needs to call the rpmsg_alloc_tx_buffer() and set the RPMSG_BUF_HELD flag and then call the nocpy rpmsg_send to send the buffers.
* Do you have wrapper rpmsg API for this step?
* whenever user call the rpmsg_alloc_tx_buffer(), does it always suggested no-copy? If this is the case, why not set the flag in this API and rename this API to suggest it is for 0-copy?

* the totlen is uint16_t, it looks like it will limit the buffer size. However, the good thing is can reuse the reserved flag, and don't have to introduce new fields.

Thanks,
Wendy

[Marek Novák]

Hello Wendy,

I believe a nice flow chart is worth a thousand of words.
So I have prepared one!

I hope it explains the reception/transmission sequence...

The first "section" shows a situation where the first side sends the data in a copy way and the other receives it in a zero-copy way. The second section shows a zero-copy transmission and copy reception and the last section shows a full zero-copy transaction...

Feel free to ask for any additional explanation.

Regards,
Marek Novak
NXP Semiconductors

2016-08-25 2:34 GMT+02:00 Jiaying Liang <wendy...@xilinx.com>:

HI Marek, Petr,

Here is my understanding of the patch:
* The tx send controls whether the it is zero copy by setting the RPMSG_BUF_HELD flag.
* The rx side, if the flag is set, it will not return the buffer in the rx callback.
* Either rx or tx side need to call  rpmsg_release_rx_buffer() to release the buffer.

Is my understanding correct?

* When working with current Linux kernel, we cannot use this feature, is it correct? Do you have any plan for Linux kernel rpmsg upstream support?
* Tx side needs to call the rpmsg_alloc_tx_buffer() and set the RPMSG_BUF_HELD flag and then call the nocpy rpmsg_send to send the buffers.
     * Do you have wrapper rpmsg API for this step?
     * whenever user call the rpmsg_alloc_tx_buffer(), does it always suggested no-copy? If this is the case, why not set the flag in this API and rename this API to suggest it is for 0-copy?

* the totlen is uint16_t, it looks like it will limit the buffer size. However, the good thing is can reuse the reserved flag, and don't have to introduce new fields.

Thanks,
Wendy

From: open...@googlegroups.com [mailto:open-amp@googlegroups.com] On Behalf Of Jiaying Liang
Sent: Wednesday, August 24, 2016 9:17 AM
To: open...@googlegroups.com
Cc: Petr Lukas; Michal Princ
Subject: [open-amp] RE: RPMsg Extension layer including zero-copy

Thanks Marek,
Wendy

From: open...@googlegroups.com [mailto:open-amp@googlegroups.com] On Behalf Of Marek Novak
Sent: Wednesday, August 24, 2016 6:25 AM
To: open...@googlegroups.com
Cc: Petr Lukas; Michal Princ
Subject: [open-amp] RPMsg Extension layer including zero-copy

Hello dear community, Hello Wendy,

Please find attached a patch implementing the zero-copy for RPMsg.
I have blindly ported the zero copy from an older version of RPMsg OpenAMP, which was used internally here in NXP, to use libmetal API.
I hope it should be ok. I could not run it on a real hardware, since we currently use internally for our microcontroller targets the RPMsg Lite.

The patch is generated against current head of openamp-libmetal branch (SHA1: 536f103ee4f7d4).

Please feel free to comment on the patch and to suggest any improvements!
Have a nice day,
Marek NOVAK
NXP Semiconductors

PS & BTW:
Do you think we could publish our RPMsg Lite implementation targeting mainly platforms, which are low on resources in let’s say: https://github.com/OpenAMP/RPMsg-Lite  ?
I think Petr Lukas has sent you recently some information about it.
--
You received this message because you are subscribed to the Google Groups "open-amp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-amp+unsubscribe@googlegroups.com.

To post to this group, send email to open...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
--
You received this message because you are subscribed to the Google Groups "open-amp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-amp+unsubscribe@googlegroups.com.

To post to this group, send email to open...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

--
You received this message because you are subscribed to the Google Groups "open-amp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-amp+unsubscribe@googlegroups.com.

To post to this group, send an email to open...@googlegroups.com.