Communication FT - Presentation CommonAPI with mw::com

[LittleHuba]

Participants

• @LittleHuba
• Omar EWEDA
• Weber Marius
• @SebastianGrob
• @lurtz
• Khalid RAMADAN
• Mina Hamdi
• @kalu-an
• @alexandruiulian10
• @vinodreddy-g
• AbhishekGOYAL
• Ahmed ElAbyad
• Karim Wafik
• Desoky Abdelqawy
• Mikhael Thomas
• Mittag Lukas
• bish
• Andreas Beetz

Minutes

Proposal only contains the CommonAPI frontend and no binders.

Binders may come in a later proposal, but there is no apparent reason why these binders could not also be proposed to mw::com.

Q: Could you provide more insight what you mean with strict buffer synchronization
A: Control channel is separated from data channel.

Safety challenges when sending pointers from one application to another.
Memory access of the transferred pointers fully relies on the recipient having access to the same memory that the sender has. Mapping the memory is not necessarily ensured by the communication framework.

Q: Where is the evidence that zero-copy performs worse for small data samples?
A: Shown during session. Difference is 4 microseconds on average.
Code for performance measurement would need to be shared to validate that the numbers depict reality.
Sequence diagram shows that performance data might not be fully reliable because it involves a kernel call to retrieve time at every cycle. This can add significant jitter.

Claim: CommonAPI is a defacto standard. S-CORE should use defacto standards
mw::com shares many similarities with ara::com and therefore is defacto standard API with wide adoption.
=> no clear benefit in switching to CommonAPI

Claim: CommonAPI is widely used in infotainment world
S-CORE is tailored to ADAS world. While there were discussions whether to add support for other domains, this would happen on application framework level. Moving safety relevant code to a framework written for a non-safety related world can have serious consequences in terms of unsafe coding style.

CommonAPI does not come for free. Switching involves modifying parts of the frontend to be in line with S-CORE baselibs.
CommonAPI on top of mw::com does not make sense. Both serve the same architectural goal of abstracting differences in communication channels, duplicating this layer only adds latency with no apparent gain.

Claim: mw::com has no way to hook in custom memory management
mw::com supports this already via TypedMemory concept. Interface must be implemented by user since it is very use case dependent.

Rust support in CommonAPI currently lacking. We would have to spend effort to add this support which we already have added to mw::com in big parts.

Discussion was cut short since time slot ended. Coming Monday we will have 30 minutes to finish the discussion.
Please prepare your comments/questions in advance.
Integration of CommonAPI and MW COM.pdf

[SebastianGrob]

To Velao, Khalid Ramadan and mina-hamdi/@aelabyad,
Could you please share the source code for the tests you used to run the benchmarks?

[aelabyad]

mw_com_benchmark.zip

[aelabyad]

Minutes

Proposal only contains the CommonAPI frontend and no binders.

Binders may come in a later proposal, but there is no apparent reason why these binders could not also be proposed to mw::com.

Q: Could you provide more insight what you mean with strict buffer synchronization A: Control channel is separated from data channel.

Safety challenges when sending pointers from one application to another. Memory access of the transferred pointers fully relies on the recipient having access to the same memory that the sender has. Mapping the memory is not necessarily ensured by the communication framework.

Shared Memory handles is what is shared at the binder level, however what is exposed at the application level is the shareableBuffer instance which inherits from unique_ptr. any shared memory based IPC requires both server and client processes to have access to the same shared memory. Safety mainly depends on the binder implementation which will be covered through its AoUs. There is actually a benefit in the proposed solution since the complete spatial FFI can be guarnteed by the copy based path already. Temporal FFI can already be satisfied by CommonAPI timeout mechanisms

Q: Where is the evidence that zero-copy performs worse for small data samples? A: Shown during session. Difference is 4 microseconds on average. Code for performance measurement would need to be shared to validate that the numbers depict reality. Sequence diagram shows that performance data might not be fully reliable because it involves a kernel call to retrieve time at every cycle. This can add significant jitter.

Measurement is taken over 10000 samples to average any kind of noise in both measurements to make the comparative analysis relevant. we remeasured without using Kernel Calls and it shows the same numbers "ClockCycles()"

Claim: CommonAPI is a defacto standard. S-CORE should use defacto standards mw::com shares many similarities with ara::com and therefore is defacto standard API with wide adoption. => no clear benefit in switching to CommonAPI

Our claim was not that SCORE should use defacto standards. However, we do not think that reusing already available standards that meet the SCORE requirements is a bad idea. in fact we think that SCORE should use whatever is more optimized that will lead to better performance. Our claim was a reply to the idea that mw:com is adopted while CommonAPI is not adopted in the industry even though CommonAPI is a defacto standard in Automotive as a service bus.

Claim: CommonAPI is widely used in infotainment world S-CORE is tailored to ADAS world. While there were discussions whether to add support for other domains, this would happen on application framework level. Moving safety relevant code to a framework written for a non-safety related world can have serious consequences in terms of unsafe coding style.

It is understood that S-CORE is tailored to ADAS world with the target of having this in an SDV platform. if there are merits in using a custom solution that is optimized for ADAS use cases then that is definitely the valid choice for S-CORE. However, if there is a valid technical solution that is fitting both IVI and ADAS then we don't see the reason for going out of our way to develop a solution that is not already adopted by Infotainment systems.

CommonAPI does not come for free. Switching involves modifying parts of the frontend to be in line with S-CORE baselibs.

If we agree on this as a technical solution, then we can discuss the technical details of what needs to be migrated from within CommonAPI specially that CommonAPI has zero dependency on external libs currently (i.e. no dependency on boost).

CommonAPI on top of mw::com does not make sense. Both serve the same architectural goal of abstracting differences in communication channels, duplicating this layer only adds latency with no apparent gain.

The reason We developed a mw::com binder for CommonAPI was because at the beginning of this we understood that mw::com and lola IPC were entangled together. and this server to prove in our POC CommonAPIs ability to support zero copy shared memory based IPC. However, we agree that the better approach would be to use lola IPC as a binder directly instead of mw::com.

Claim: mw::com has no way to hook in custom memory management mw::com supports this already via TypedMemory concept. Interface must be implemented by user since it is very use case dependent.

We couldn't find an example of how typed memory can be used to do custom allocation for custom memory management but it seems like using pmr could help with that, please confirm our understanding and let us know if there is an example of how custom memory allocation be done

Rust support in CommonAPI currently lacking. We would have to spend effort to add this support which we already have added to mw::com in big parts.

Agreed, Rust Support for CommonAPI is still not available.

Discussion was cut short since time slot ended. Coming Monday we will have 30 minutes to finish the discussion. Please prepare your comments/questions in advance. Integration of CommonAPI and MW COM.pdf