Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maximising performance #50

Open
wonk-andy opened this issue Sep 16, 2024 · 3 comments
Open

Maximising performance #50

wonk-andy opened this issue Sep 16, 2024 · 3 comments
Assignees
Labels

Comments

@wonk-andy
Copy link

I posted these questions earlier on the Community Forum but it possibly makes more sense to ask them here.

I am trying to maximise the performance of the communication between the i.MX8M Mini Cortex-M4 (bare metal) and a QNX application running on the Cortex-A53 using the librpmsg_lite-imx library.

Some questions...

I am currently sending a 212byte message every 10ms from the firmware running on the Cortex-M4 (the remote end of the connection). I'm not seeing any send errors but is that rate possible or am I missing data and not noticing, bearing in mind this is bare metal and no queue. What is the maximum theoretical throughput?

In the multicore examples in the MIMX8MM SDK both of the remote examples have files called rsc_table.[c|h] which defines a remote resource table. What is this used for? As I increase the number of buffers that defined do I need to increase VRING_SIZE?

To give some scope for adding to the size of the data being sent, I have RL_BUFFER_PAYLOAD_SIZE set to 496 and RL_BUFFER_COUNT set to 2048. Does changing these have an impact on the definition of VRING_SIZE?

-Andy.

@MichalPrincNXP
Copy link
Contributor

Hello Andy,
I am sorry for late response ... we do not have a dedicated application for the throughput measurement at the moment. It depends mainly on the platform (shared memory access) and the rpmsg-lite configuration (copy, no-copy mechanism). Very rough data captured on an imx8 board is: to send and then receive 496bytes (request+response) takes ~0.2ms/cycle when copy mechanism used, and it takes ~0.05ms/cycle when no-copy mechanism is used. Considering that, sending 212bytes message every 10ms should be far from these limits and should work fine.

rsc_table belongs to the Linux mechanism called remoteproc used for auxiliary core resources initialization/setup/start. I am not sure if QNX provides that remoteproc component, probably not.

As for the VRING_SIZE, yes it depends on the RL_BUFFER_COUNT, so once you change the RL_BUFFER_COUNT the preallocated VRING_SIZE should be adjusted. Please, have a look here how the VRING_SIZE is calculated for some platforms.

Hope it helps
Regards
Michal

@wonk-andy
Copy link
Author

Hello Michal,

Apologies for the slow response, I managed to catch covid and wasn't capable of working.

Thanks for the information. Based on your feedback, it looks like we should be able to get the data throughput that we need.

The implementation of librpmsg_lite-imx uses the standard RPMsg-Lite library and uses a slightly peculiar mechanism to override some of the standard files with i.MX specific ones. Does that mean that I can dispense with the rsc_table parts?

Thanks,

Andy.

@MichalPrincNXP
Copy link
Contributor

@wonk-andy , I am not sure about the rsc_table part, I have asked my colleague, will get back once I have a response...
Michal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants