HLD for SAI Validation and PySAI #2039
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
|
||
|
|
||
| ##### 6.2.1 PySAI Code-gen | ||
| 1. Parsing: parse.py uses libclang to extract enums, structs, and function signatures from SAI headers. These are mapped to Pydantic models as intermediate representation. |
There was a problem hiding this comment.
This is a very promising proposal and holds a lot of potential. Please consider presenting this in the OCP SAI community forum as well.
- Can you provide some details about the design choice of say not directly converting from SAI C headers to Python API say by using ctypesgen and then build higher layer Python classes on top of Ctypes APIs?
- Do you plan to use the intermediate artefacts like the Pydantic models for some other purpose in the future?
There was a problem hiding this comment.
Thanks for your suggestions! Here are the answers
-
Our code generator produces direct Python bindings to all SAI C APIs using ctypes, enabling low-level access to the interface. However, to improve usability for developers, especially when working interactively or managing dependencies in object-oriented environments such as IPython, we also provide higher-level SAI object abstractions. These classes wrap the core functionality—including object creation/removal, bulk operations, attribute management, and statistics—making it simpler and more intuitive to work with SAI directly from Python.
-
We plan to leverage the intermediate artifacts, especially the Pydantic models, for future use. Pydantic schemas make it explicit which flags and attribute values are valid, supporting better validation and code clarity when handling SAI structures and comments. The current OCP-SAI code generation primarily uses Perl scripts, which can be difficult to extend and maintain. By introducing YAML files that formally specify SAI models, we can decouple the generation logic for various tools (Thrift, SWIG, serialization, etc.), streamline development, and facilitate new integrations—such as generating boilerplate for sonic-sairedis.
| 1. The testbed should be self-contained, using only a single switch without dependence on external devices like a fanout switch or server. | ||
| 2. Call SAI APIs in the same way as syncd, to reflect the real-world performance of SAI API invocations in SONiC. | ||
| 3. Provide interactive mode for step-by-step debugging and incremental developing. | ||
| 4. Support sairedis.rec recording and replay for the test process, with automatic filtering and isolation of entries based on relevance. |
There was a problem hiding this comment.
As discussed in the community meeting, please explain how a SONiC sairedis.rec log can be replayed to PySAI. Please explain how the Virtual OIDs are converted to Real OIDs.
There was a problem hiding this comment.
Our approach to converting Virtual Object IDs (VIDs) to Real Object IDs (RIDs) mirrors the strategy used by sonic-sairedis. During replay of a sairedis.rec log in PySAI, we maintain a dedicated mapping between VIDs and RIDs:
- For each object creation operation, we associate the VID referenced in the sairedis.rec with the actual RID returned by libsai.so after the operation is completed.
- For set and update operations, we look up the corresponding RID for each VID in our mapping, and pass the request using the RID to libsai.so for accurate execution.
3 participants
SAI Validation is a Python-based framework for testing and developing SAI C APIs. It fills two key gaps: