-
Notifications
You must be signed in to change notification settings - Fork 478
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
Vendor custom attributes after SAI_*_ATTR_END #2099
Comments
I created attribute API metadata PR here: #2100 |
plus @JaiOCP for visibility |
By default disabled. If enabled, it will use SAI metadata and libsai version returned by sai_api_version_query to verify if given attribute during SAI discovery process was introduced in the current libsai version or below that version. This feature is partial solution to this problem: sonic-net/sonic-buildimage#20725, more here: opencomputeproject/SAI#2099
Few questions, please clarify -
Thanks |
First of all please don't confuse extensions with custom attributes.
Addressing your questions:
|
By default disabled. If enabled, it will use SAI metadata and libsai version returned by sai_api_version_query to verify if given attribute during SAI discovery process was introduced in the current libsai version or below that version. This feature is partial solution to this problem: sonic-net/sonic-buildimage#20725, more here: opencomputeproject/SAI#2099
This issue is related to recently discovered problem: sonic-net/sonic-buildimage#20725
During syncd boot sequence we are performing discovery operation on the device iterating GET via all OID attributes to figure out what objects are existing on the device.
Recent problem is that in syncd we use latest headers that for example added SAI_PORT_ATTR_SELECTIVE_COUNTER_LIST attribute which was introduced in SAI version v1.15.0, but SAI version used in sonic was v1.14.0. This should not be and issue, since from version v1.10.0 SAI is binary backward compatible.
Unfortunately there are 2 problems here.
Having custom attributes after ATTR_END is not backward compatible, it may be handy for vendors to keep enum id small value instead of 0x10000000 where custom attr range starts, but it causes issue describe
NOTE: Vendors should always use SAI_*_ATTR_CUSTOM_RANGE_START to implement internal attributes in their SAI.
To mitigate partially this issue i'm working on enhancing SAI metadata to include SAI version for each attribute, and query only attributes that are up to the version of SAI that vendor is returning. This solution is only partially solving this issue since there are other 2 cases here:
I think permanent solution is to make sure all vendors will have not attributes after ATTR_END so they will be backward compatible. And current partial solution can be checking attributes version a gains plugged SAI version
Please give your thoughts.
Visual example:
So you can see, when syncd is doing query SAI_PORT_ATTR_SELECTIVE_COUNTER_LIST it's actually getting SAI_PORT_ATTR_CUSTOM_VENDOR_5, which caused issue at the first place.
The text was updated successfully, but these errors were encountered: