Add flow control service #394
Conversation
Create a dedicated channel for the endpoints flow control. This channel implements the software control allowing to: - inform the remote side that it is ready or not to communicate, - be informed by the remote endpoint that it can start or must stop to send rpmsg. In addition the channel can help to bind the local and the remote endpoint after a NS announcement as it set the local endpoint dest_addr if is current value is RPMSG_ADDR_ANY. To enable the feature the VIRTIO_RPMSG_F_FC must be set in the vdev structure in the resource table. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Increase readability by creating sub-chapter for endpoint and device callbacks. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Add documentation on the flow control callback and API to inform the remote side about an endpoint state. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
If the virtio rpmsg device feature VIRTIO_RPMSG_F_FC is set, register the rpmsg flow control endpoint. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
If the WITH_RPMSG_FLOW_CONTROL config is defined: - set the VIRTIO_RPMSG_F_FC bit in the resource tables, - return an error if the remote side does not support it. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Add an example of the flow control usage. The host: - waits the reception of a flow control RPMSG_EPT_FC_ON before starting to send message, - pauses when it receive a !RPMSG_EPT_FC_ON flow control. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
The series sent on Linux mailing list is available here: |
|
|
||
| int rpmsg_set_flow_control(struct rpmsg_endpoint *ept, uint32_t flags) | ||
| { | ||
| struct rpmsg_ept_msg msg; |
There was a problem hiding this comment.
remove the extra space before msg
| * An NS announcement has been sent to the remote side which answer with flow control. | ||
| * Register the remote endpoint as default destination endpoint. | ||
| */ | ||
| if (_ept->dest_addr == RPMSG_ADDR_ANY) |
There was a problem hiding this comment.
this doesn't resolve the first creator of endpoint want to notify the flow info initially.
There was a problem hiding this comment.
Agree, NS_ack would help for this
|
|
||
| msg.flags = flags; | ||
| msg.src = ept->addr; | ||
| msg.dst = ept->dest_addr; |
There was a problem hiding this comment.
As I mention in other PR, the separated flow control isn't good because:
- it isn't efficient to send a dedicated message for the flow control, since the same info could piggyback as a flag field in normal data transfer in most case.
- ON/OFF info isn't enough in the advanced flow control since the additional info is required(e.g. the slide window, round trip delay, congestion etc..).
So I would expect the flow control is part of the protocol design, and the general flow control service is useless.
There was a problem hiding this comment.
Thanks for your feedback, could please send your feedback on Linux mailing list instead. As this feature impact both, the Linux and the OpenAMP. Having a single place would ease discussion.
If you have not subscribed to the Linux remote proc mailing list you can get the "mbox" on patchwork
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=643501
|
This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity. |
This series proposes an implementation for the rpmsg virtio transport backend, of the signaling API proposed by Deepak Kumar Singh on Linux:
"rpmsg and glink signaling API support" [1]
The aim of the pull request is to offer the possibility for an endpoint to inform a remote endpoint about its state, based on a software flow control[2].
For this a new rpmsg service( with a fixed address 64) is proposed.
It is responsible for:
For the rpmsg virtio transport layer the service is negotiated thanks to the virtio feature flag: VIRTIO_RPMSG_F_FC
Notice that this pull request introduces new feature in the rpmsg protocol, So it has to be aligned with Linux implementation.
For this a pull request will sent to the linux remoteproc mailing to implement pending feature.
[1]https://lkml.org/lkml/2022/1/18/867
[2]https://en.wikipedia.org/wiki/Software_flow_control