-
Notifications
You must be signed in to change notification settings - Fork 9
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
API refinement: make RX pipeline zero-copy as a side effect of the OOO reassembly support #38
Conversation
…ld naming scheme doesn't fit in the 31 character limit required by MISRA C:2012. Alternatively we could replace some other part of the name but it is hard to ensure consistency with the subject RX entities
Kudos, SonarCloud Quality Gate passed! |
Just want to document what we talked about in the dev call, the zero-copy design assumes that udpard can directly take over ownership of the buffer from the network stack. A lot of microcontrollers use DMA to store the payload buffer in a section of memory that udpard would not be able to take ownership of and would require making a copy. Are we going to provide an API to allow for this case? |
Do we have a ticket for this? I think almost all applications are going to want the contiguous chunk of memory and not the fragments, so we're kind of feature incomplete without this function. |
The plan is to let the application copy the data from the memory managed by the NIC driver into a new buffer and move it into the library. This solution does not require new API. We can optionally provide convenience functions for this later. |
Close #36
Add RX frame parser (a simple function) with tests.
Update the RX pipeline as described in https://forum.opencyphal.org/t/refined-requirements-for-the-rx-pipeline-in-libudpard/1938.
Pros:
Cons:
udpardRx*Receive
functions take ownership of the payload buffer.The docs are a bit rough around the edges but the idea should be clear. One missing feature is a trivial helper function that takes payload fragments and returns a contiguous chunk of memory instead (this is expensive both memory-wise and time-wise).