BYO (Bring-Your-Own) data plane app HLD #464
Conversation
| After initialization, the data plane app will be able to: | ||
|
|
||
| - Receive/Send packets from/to netdev | ||
| - Use SAI API to program the ASIC |
There was a problem hiding this comment.
Would it be fair to say that using SAI APIs to program the ASIC would be optional? The existing SAI apis for flow management may or may not work for a custom data plane, so a BYO data plane may want to use low-level ASIC SDK APIs to manage ASIC tables.
There was a problem hiding this comment.
Hi Ashutosh, since the BYO data plane is essentially the customer's own implementation, so they could use the platform-dependent APIs or SAI for building the data plane. However, using SAI will give them the advantage of building platform independent applications.
Here, since the behavior of the platform-dependent APIs are not under control of SAI, so they are not included in the doc. And if there are more valid flow actions, we can also make SAI flow APIs supports it as well. The process should be similar as how SAI is working today. :D
Also sorry for the late reply. Just came back from vacation.
There was a problem hiding this comment.
I have updated the doc with more details and also have this ability noted in the doc too.
There was a problem hiding this comment.
What's the difference between this SAI api vs rte flow api used by DPDK app for hareware flow offloading?
|
|
||
| Even further, these 2 sources sometimes might need to work together in certain scenarios. For example, when a VNET mapping is updated, we need to update the VNET mapping entry as well as triggering flow resimulation to update all the flow entries that are related to this VNET mapping. | ||
|
|
||
| Hence we need a design to avoid the same set of SAI APIs being called in 2 different processes accidentally and causing problems, such as managing the stage entries, as the last caller will overwrite the ASIC state without any synchronization and knowledge from the other side. |
There was a problem hiding this comment.
I think this can be resolved by capability query and enabling only one path for certain set of APIs.
There was a problem hiding this comment.
yea, will update the doc and remove the proxy, which is actually my first version of design: https://github.com/r12f/DASH/blob/9d3c8ec2d9bc255ca72328cdce24a7fe9a037ac5/documentation/dataplane/dash-byo-data-plane-app.md.
XD
|
hi @r12f - is this PR still needed/in progress? TY! |
Motivation
By default, DASH technology providers will provide their own data plane app. This is usually closed source and can satisfy the DASH community requirement. However, in some cases, DASH users might want to use their own data plane app due to some reasons, such as: private protocol support or support special logic in packet handling that is not supported by DASH technology providers. In this case, you can enable DASH BYO data plane app.
For example:
Change Summary
This change adds the HLD for how to enable BYO data plane app and how the high level architecture looks like.
Future works
Some cases might also require to run both data plane app side by side as hybrid mode. The design will come later.