RO Attr (switch obj) to get a list of supported obj types

[bandaru-viswanath]

A new RO attribute to switch object that returns the list of supported object types that the underlying SAI adapter can support. This allows the clients of SAI to understand the abilities of the underlying silicon as well as the SAI adapter to support the SAI feature set.

[marian-pritsak]

I think that adding a new API to https://github.com/opencomputeproject/SAI/blob/master/inc/saiobject.h seems more logical.

[kcudnik]

yes, new api would make sense to me, since to get this list of supported objects you would need to create swtich first, from the other hand what if there are multiple asic units in the SAI and each of them support different set of objects ?

assuming that depeneding on api/attribute meaning, api would give global support, and attr per asic unit?

[bandaru-viswanath]

@marian-pritsak , @kcudnik : So are you suggesting we add the API suggested by Marian for 'Global capabilities' where as the one I proposed would be for a per-asic capabilities ?

I am Okay with and makes sense to me. Please confirm and I will push updates.

[kcudnik]

so in this case there would be 2 apis in total?

[bandaru-viswanath]

Actually I take back my words.
The API in the saiobject.h file take switch object-id as an input parameter. So there is no such thing as Global capabilities. Besides, the saiobject.h file is meant to act on an specific object type - they take object type as a parameter and return appropriate values specific to that object type.
In my proposal, the intent is to get the capabilities in terms of all object types supported by a switch object. I don't think saiobject.h is the right place for it.
@marian-pritsak Could you please suggest a modification/addition to saiobject.h so that I can see why it may be more logical ?

[rck-innovium]

Vissu,
The proposed mechanism is a way for syncd to call the SAI adapter to get the list of supported object types and loop through the returned list and do the processing per supported object type.

The same thing can be done in syncd by walking through all the sai_api_query's api_method_table and do the processing for API types wherever it has non null callbacks.

[bandaru-viswanath]

Hi Ravindranath,

The proposed mechanism is not meant for syncd to get this attribute and loop through. syncd (in sonic world) is only making the call and returning the SAI returned list back to SONiC. No looping involved.

Also, there is no guarantee that the presence non-null callbacks would mean that the corresponding objects can be created. There may be dummy callbacks which would return UNSUPPORTED, to avoid null-pointer dereferencing in syncd.

[lguohan]

maybe the availability of sai object is conditioned on the switch object. for example, different asics are usually supported by one SAI library. I am ok with current proposal. @marian-pritsak , do you agree?