API refinement: make RX pipeline zero-copy as a side effect of the OOO reassembly support#38
API refinement: make RX pipeline zero-copy as a side effect of the OOO reassembly support#38pavel-kirienko merged 14 commits intomain2from
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*Receivefunctions 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).