Skip to content
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

Assign values to enum fields #1259

Merged
merged 2 commits into from Aug 26, 2021

Conversation

shri-khare
Copy link
Contributor

Problem

Consider a scenario where an application (adapter host) using SAI spec X
(say) warmboots to an application using new SAI spec Y (say).

If an enum is extended between X and Y with fields inserted "in between"
rather than "at the end" of the enum, the old fields can get "renumbered".
However, the SAI implementation (adapter) continues to return old enums
for previously returned objects thereby breaking the warmboot.

Possible approaches

We discussed this during June 24, 2021 weekly SAI meeting and observed:

  • This can e avoided by mandating that any new inserts to an enum will be
    "at the end" (this could mean at the end of _END block). This will keep
    the enum field values the same.
  • However, that will come at the cost of readability: newly added fields
    may be related to existing fields and thus for readability, those fields
    belong togeter. Adding those to the end scatters the related fields
    across the enum.

Solution

Thus, we agreed to go with the below approach:

  • Every enum field will have an explicit integer value assigned to it.
  • Insertions can be "in between" (maintains readability) but the next
    available unused integer value would be used for the new insertions.
  • Thus, once an integer is assigned to an enum field, it does not change
    with spec revision thereby not breaking warmboot.
  • Between SAI spec 1.6.5 to 1.8.1, saihash.h and saiacl.h had new enms
    inserted "in between".

Those will be "fixed" by assigning integer values to enum fields.

This fix will be applied to top of the sai.git tree.
This fix will then be ported to 1.8.1 and 1.8.2 will be released.

Towards that end, these patches assigns integer values to enums in
saihash.h and saiacl.h that were changed from 1.6.5 to 1.8.1

@shri-khare shri-khare changed the title Assign values to enum Assign values to enum fields Jun 29, 2021
Problem
========

Consider a scenario where an application (adapter host) using SAI spec X
(say) warmboots to an application using new SAI spec Y (say).

If an enum is extended between X and Y with fields inserted "in between"
rather than "at the end" of the enum, the old fields can get "renumbered".
However, the SAI implementation (adapter) continues to return old enums
for previously returned objects thereby breaking the warmboot.

Possible approaches
===================

We discussed this during June 24, 2021 weekly SAI meeting and observed:

- This can e avoided by mandating that any new inserts to an enum will be
"at the end" (this could mean at the end of _END block). This will keep
the enum field values the same.
- However, that will come at the cost of readability: newly added fields
may be related to existing fields and thus for readability, those fields
belong togeter. Adding those to the end scatters the related fields
across the enum.

Solution
=========

Thus, we agreed to go with the below approach:
- Every enum field will have an explicit integer value assigned to it.
- Insertions can be "in between" (maintains readability) but the next
available unused integer value would be used for the new insertions.
- Thus, once an integer is assigned to an enum field, it does not change
with spec revision thereby not breaking warmboot.
- Between SAI spec 1.6.5 to 1.8.1, saihash.h and saiacl.h had new enms
inserted "in between".

Those will be "fixed" by assigning integer values to enum fields.

This fix will be applied to top of the sai.git tree.
This fix will then be ported to 1.8.1 and 1.8.2 will be released.

This patch
===========

Towards that end, this diff fixes saiacl.h.

Specifically, below patch was first introduced in v1.7.0 and inserted enum fields 'in betweeen':
opencomputeproject@1aeb1c8

Thus,

- In 1.6.5: SAI_ACL_ENTRY_ATTR_FIELD_DSCP is 4126, SAI_ACL_ENTRY_ATTR_ACTION_SET_DSCP is 8214 etc.
- In 1.8.1: SAI_ACL_ENTRY_ATTR_FIELD_DSCP is 4134, SAI_ACL_ENTRY_ATTR_ACTION_SET_DSCP is 8216 etc.

If the application created ACL entry with SAI_ACL_ENTRY_ATTR_FIELD_DSCP
(4126) prior to warmboot, even after warmboot, a get query on that ACL
entry returns 4126 which no longer means SAI_ACL_ENTRY_ATTR_FIELD_DSCP.

This patch fixes it by assigning explicit integer values, and thus
SAI_ACL_ENTRY_ATTR_FIELD_DSCP continues to be 4126 in newer SAI specs as
well.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
Problem
========

Consider a scenario where an application (adapter host) using SAI spec X
(say) warmboots to an application using new SAI spec Y (say).

If an enum is extended between X and Y with fields inserted "in between"
rather than "at the end" of the enum, the old fields can get "renumbered".
However, the SAI implementation (adapter) continues to return old enums
for previously returned objects thereby breaking the warmboot.

Possible approaches
===================

We discussed this during June 24, 2021 weekly SAI meeting and observed:

- This can e avoided by mandating that any new inserts to an enum will be
"at the end" (this could mean at the end of _END block). This will keep
the enum field values the same.
- However, that will come at the cost of readability: newly added fields
may be related to existing fields and thus for readability, those fields
belong togeter. Adding those to the end scatters the related fields
across the enum.

Solution
=========

Thus, we agreed to go with the below approach:
- Every enum field will have an explicit integer value assigned to it.
- Insertions can be "in between" (maintains readability) but the next
available unused integer value would be used for the new insertions.
- Thus, once an integer is assigned to an enum field, it does not change
with spec revision thereby not breaking warmboot.
- Between SAI spec 1.6.5 to 1.8.1, saihash.h and saiacl.h had new enms
inserted "in between".

Those will be "fixed" by assigning integer values to enum fields.

This fix will be applied to top of the sai.git tree.
This fix will then be ported to 1.8.1 and 1.8.2 will be released.

This patch
===========

Specifically, below patch was first introduced in v1.7.0 and inserted enum fields 'in betweeen':
opencomputeproject@21bdb48

- In 1.6.5: SAI_NATIVE_HASH_FIELD_L4_SRC_PORT is 7, SAI_NATIVE_HASH_FIELD_L4_DST_PORT is 8.
- In 1.8.1: SAI_NATIVE_HASH_FIELD_L4_SRC_PORT is 15, SAI_NATIVE_HASH_FIELD_L4_DST_PORT is 16.

If the application configured SAI_NATIVE_HASH_FIELD_L4_SRC_PORT (7)
prior to warmboot, even after warmboot, a query returns 7 which no
longer means SAI_NATIVE_HASH_FIELD_L4_SRC_PORT in 1.8.1.

This patch fixes it by assigning explicit integer values, and thus
SAI_NATIVE_HASH_FIELD_L4_SRC_PORT continues to be 7 in newer SAI specs
as well.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
@shri-khare shri-khare marked this pull request as ready for review June 29, 2021 06:23
@shri-khare
Copy link
Contributor Author

The meta checks fail here: ./meta/saisanitycheck.c

META_ENUM_ASSERT_FAIL(emd, "values are not increasing by 1: last: %d current: %d, should be marked as @flags?", last, value);

This is expected as we are now introducing consecutive enum fields that are not increasing by 1 by design.
Perhaps, we should remove this check from saisanitycheck.c?

Copy link
Collaborator

@kcudnik kcudnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This problem is addressed already here: #1256
This change will make sure enum numbers don't change over time, and no need to explicit numbering

There is no need for gaps in enums like SAI_NATIVE_HASH_FIELD_IPV6_FLOW_LABEL vs SAI_NATIVE_HASH_FIELD_NONE. Old enums should exists, and should be marked as depreacakted.

@kcudnik
Copy link
Collaborator

kcudnik commented Jun 29, 2021

This is expected as we are now introducing consecutive enum fields that are not increasing by 1 by design.
Perhaps, we should remove this check from saisanitycheck.c?

no, this check must stay, to make sure enums are consistent, there is no need to introduce gaps in enums.
metadata and metadata utils have a lot of assumption based on those sanity checks, and if those will be removed, then metadata utils will also break. for example currently enums values must increase (be sorted) since metadata utils search is based on this feature, and enum value cannot be determined at perl parsing time, since enums dont have explicit values and some enums are based on BASE + X value, it's much easier to compile metadata and do sanity checks, and this is what is happening right now. there is still away to maintains certain enums in "ranges" alike acl_entry fields and actions, by adding enums at the end of each specific range, since that range have explicit base

@shri-khare
Copy link
Contributor Author

Thanks Kamil.

Posted few questions about this here: #1256 (comment)

@kcudnik
Copy link
Collaborator

kcudnik commented Jun 29, 2021

Posted few questions about this here: #1256 (comment)

done


/**
* @brief End of Rule Match Fields
*/
SAI_ACL_ENTRY_ATTR_FIELD_END = SAI_ACL_ENTRY_ATTR_FIELD_TAM_INT_TYPE,
SAI_ACL_ENTRY_ATTR_FIELD_END = SAI_ACL_ENTRY_ATTR_FIELD_DST_IPV6_WORD0,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

previous was correct, i assume that SAI_ACL_ENTRY_ATTR_FIELD_END will shift (can only increase from SAI to SAI)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


/**
* @brief End of Rule Actions
*/
SAI_ACL_ENTRY_ATTR_ACTION_END = SAI_ACL_ENTRY_ATTR_ACTION_SET_VRF,
SAI_ACL_ENTRY_ATTR_ACTION_END = SAI_ACL_ENTRY_ATTR_ACTION_ADD_VLAN_PRI,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

previous was correct, i assume that SAI_ACL_ENTRY_ATTR_ACTION_END will shift (can only increase from SAI to SAI)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


/**
* @brief End of ACL Table Match Field
*/
SAI_ACL_TABLE_ATTR_FIELD_END = SAI_ACL_TABLE_ATTR_FIELD_TAM_INT_TYPE,
SAI_ACL_TABLE_ATTR_FIELD_END = SAI_ACL_TABLE_ATTR_FIELD_DST_IPV6_WORD0,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

previous was correct, i assume that SAI_ACL_TABLE_ATTR_FIELD_END will shift (can only increase from SAI to SAI)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kcudnik
Copy link
Collaborator

kcudnik commented Jul 2, 2021

Actually this PR is not needed, i addressed this in comment #1259 (review), after checking #1256 those checks will be enforced

@kcudnik
Copy link
Collaborator

kcudnik commented Jul 6, 2021

if you want to keep those values,

AI_ACL_ENTRY_ATTR_FIELD_IP_PROTOCOL = SAI_ACL_ENTRY_ATTR_FIELD_START + 0x1b,

it would be better to reorder those enums to achieve desired values, it would have better looking, and after enum lock PR merged, you never have to assign them explicitly, since they always will be locked


/**
* @brief Native hash field source IPv4.
*
* Also, refers to the outer source IPv4
* in case for encapsulated packets
*/
SAI_NATIVE_HASH_FIELD_SRC_IPV4,
SAI_NATIVE_HASH_FIELD_SRC_IPV4 = 0x00000019,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this enum must bat a this place and not at the end when it was previously there? SRC/DST enums are grouped together even in this configuration so what the point to not make those enums not continuous ?

@kcudnik
Copy link
Collaborator

kcudnik commented Jul 7, 2021

This change #1274 allows to not ordered enum values and should accept your changes

@rlhui
Copy link
Collaborator

rlhui commented Jul 13, 2021

@JaiOCP , @tushar-ty , @marian-pritsak , please help to review/approve as well. Thanks.

@rlhui
Copy link
Collaborator

rlhui commented Jul 15, 2021

@JaiOCP , @tushar-ty , @marian-pritsak , please help to review/approve as well. Thanks.

@itaibaz , @ashutosh-agrawal , @rck-innovium - please feel free to review/approve as well. Thanks.

Copy link
Contributor

@JaiOCP JaiOCP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we know what's the last enum value to be used for new enums

@kcudnik
Copy link
Collaborator

kcudnik commented Jul 22, 2021

How do we know what's the last enum value to be used for new enums

you guess XD if you guess wrong, metadata validator will show you previous and current value

@JaiOCP
Copy link
Contributor

JaiOCP commented Jul 22, 2021

How do we know what's the last enum value to be used for new enums

you guess XD if you guess wrong, metadata validator will show you previous and current value

Thanks Kamil,
Would it make sense to have a "XXX_ATTR_LAST_ENUM" always updated with last value so that programmer do not have to hunt or guess the value.
How would MD checker catch a value if it is indeed the last but not contagious to the previous last enum value.

@kcudnik
Copy link
Collaborator

kcudnik commented Jul 22, 2021

How would MD checker catch a value if it is indeed the last but not contagious to the previous last enum value.

magic ! :P all enums must be contagious, even in respective ranges (there are some exceptions like sai_status_t or bit field based enums, and if enum value is duplicate then metadata will throw error on that, also not always you need to hunt last value, if you are adding enum at the end of list, you dont need to specify it explicitly, only when you are inserting enum in the middle
check here https://github.com/opencomputeproject/SAI/blob/master/meta/saisanitycheck.c#L5090

im not sure about concept with XXX_ATTR_LAST_ENUM, if you mean that this enum is artificially generated and explicitly set to a last value, then it will not work, since not always you want to add enum at the end, there are ranges based on 0x1000 index for example in hostif and acl, and you want to add specific value at the end of that specific range

@JaiOCP
Copy link
Contributor

JaiOCP commented Jul 22, 2021

How would MD checker catch a value if it is indeed the last but not contagious to the previous last enum value.

magic ! :P all enums must be contagious, even in respective ranges (there are some exceptions like sai_status_t or bit field based enums, and if enum value is duplicate then metadata will throw error on that, also not always you need to hunt last value, if you are adding enum at the end of list, you dont need to specify it explicitly, only when you are inserting enum in the middle
check here https://github.com/opencomputeproject/SAI/blob/master/meta/saisanitycheck.c#L5090

im not sure about concept with XXX_ATTR_LAST_ENUM, if you mean that this enum is artificially generated and explicitly set to a last value, then it will not work, since not always you want to add enum at the end, there are ranges based on 0x1000 index for example in hostif and acl, and you want to add specific value at the end of that specific range

I like magic :)
Yes, I was thinking of autogenerated last enum value but I see your point. It will indeed get tricky for ranges.

@kcudnik
Copy link
Collaborator

kcudnik commented Jul 23, 2021

@JaiOCP @lguohan @shri-khare i make git diff 2cc5ba0 origin/master where that commit is branch (tag: v1.6.5) and i found other attributes added in the middle besides acl:

attributes between 1.6.5 and origin/master that caused shift in enums:

  • many ACL attributes an HASH (addressed in this PR)
  • many SAI_SWITCH_ATTR_* added in the middle
  • many shifts in SAI_MACSEC_SC_ATTR_*
  • many shifts in SAI_MACSEC_SA_ATTR_*
  • segmentroute api was rename to SRV6, cause to shift many SAI_NEXT_HOP_ATTR_*
  • many SAI_PORT_INTERFACE_TYPE_* added in the middle
  • many SAI_PORT_ATTR_* added in the middle
  • many SAI_PORT_STAT_* added in the middle
  • many SAI_TUNNEL_ATTR_* added in the middle

many other attributes were added but at the end of list, so does not break anything

Should this be fixed before merging this? or you just want acl and hash, ignoring other changes? we can actually make fix for that even after marge this, but i will need a base commit ID from which we want to be binary backward compatible, but that fix would need to be on master, and from master we would check compatibility. There is also some issue, that entire segment route object was renamed to srv6 object in the meantime

@JaiOCP
Copy link
Contributor

JaiOCP commented Jul 23, 2021

@JaiOCP @lguohan @shri-khare i make git diff 2cc5ba0 origin/master where that commit is branch (tag: v1.6.5) and i found other attributes added in the middle besides acl:

attributes between 1.6.5 and origin/master that caused shift in enums:

  • many ACL attributes an HASH (addressed in this PR)
  • many SAI_SWITCH_ATTR_* added in the middle
  • many shifts in SAI_MACSEC_SC_ATTR_*
  • many shifts in SAI_MACSEC_SA_ATTR_*
  • segmentroute api was rename to SRV6, cause to shift many SAI_NEXT_HOP_ATTR_*
  • many SAI_PORT_INTERFACE_TYPE_* added in the middle
  • many SAI_PORT_ATTR_* added in the middle
  • many SAI_PORT_STAT_* added in the middle
  • many SAI_TUNNEL_ATTR_* added in the middle

many other attributes were added but at the end of list, so does not break anything

Should this be fixed before merging this? or you just want acl and hash, ignoring other changes? we can actually make fix for that even after marge this, but i will need a base commit ID from which we want to be binary backward compatible, but that fix would need to be on master, and from master we would check compatibility. There is also some issue, that entire segment route object was renamed to srv6 object in the meantime

Given that no one has complained for these attributes and warm boot, I would say its safe to fix these attributes while we are at it.

@lguohan What do you think?

@kcudnik
Copy link
Collaborator

kcudnik commented Aug 17, 2021

I wrote a tool to list those attributes, and this also will be later doing validation on each PR. couple infos:
1.6.5 is on 2cc5ba0, diverges from master on ec7e055 (1.6.0)
1.8 is on 5254200, diverges from master on 5a98bc3 (1.8.0)

so diff ec7e055 to 2cc5ba0 (master to 1.6.5) (excluding acl_table, acl_entry, tam_int and macsec:

ERROR: check ! SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE value is 0x00000014, but on was 0x10000001 on commit ec7e055
ERROR: check ! SAI_VLAN_ATTR_TAM_OBJECT value is 0x00000015, but on was 0x10000002 on commit ec7e055

this vlan can be skipped, i remember bringing it back from custom range to attr range

5a98bc3 to 5254200 has no changes

and ec7e055 to origin/master (total 347 enum values affected, too much to list here but those are numbers:

     31 SAI_ACL_ACTION_TYPE_
      1 SAI_LAG_ATTR_SYSTEM_PORT_AGGREGATE_ID
     21 SAI_NATIVE_HASH_FIELD_
      9 SAI_NEXT_HOP_ATTR_
    114 SAI_PORT_
     12 SAI_PORT_INTERFACE_TYPE_
      1 SAI_STATS_MODE_READ
      1 SAI_STATS_MODE_READ_AND_CLEAR
    152 SAI_SWITCH_
      1 SAI_TUNNEL_TERM_TABLE_ENTRY_ATTR_ACTION_TUNNEL_ID
      1 SAI_TUNNEL_TERM_TABLE_ENTRY_ATTR_SRC_IP
      1 SAI_TUNNEL_TERM_TABLE_ENTRY_ATTR_TUNNEL_TYPE
      1 SAI_VLAN_ATTR_CUSTOM_IGMP_SNOOPING_ENABLE
      1 SAI_VLAN_ATTR_TAM_OBJECT

@kcudnik kcudnik merged commit dfaa98c into opencomputeproject:master Aug 26, 2021
@kcudnik kcudnik mentioned this pull request Aug 26, 2021
rlhui pushed a commit that referenced this pull request Sep 27, 2021
Problem
========

Consider a scenario where an application (adapter host) using SAI spec X
(say) warmboots to an application using new SAI spec Y (say).

If an enum is extended between X and Y with fields inserted "in between"
rather than "at the end" of the enum, the old fields can get "renumbered".
However, the SAI implementation (adapter) continues to return old enums
for previously returned objects thereby breaking the warmboot.

Possible approaches
===================

We discussed this during June 24, 2021 weekly SAI meeting and observed:

- This can e avoided by mandating that any new inserts to an enum will be
"at the end" (this could mean at the end of _END block). This will keep
the enum field values the same.
- However, that will come at the cost of readability: newly added fields
may be related to existing fields and thus for readability, those fields
belong togeter. Adding those to the end scatters the related fields
across the enum.

Solution
=========

Thus, we agreed to go with the below approach:
- Every enum field will have an explicit integer value assigned to it.
- Insertions can be "in between" (maintains readability) but the next
available unused integer value would be used for the new insertions.
- Thus, once an integer is assigned to an enum field, it does not change
with spec revision thereby not breaking warmboot.
- Between SAI spec 1.6.5 to 1.8.1, saihash.h and saiacl.h had new enms
inserted "in between".

Those will be "fixed" by assigning integer values to enum fields.

This fix will be applied to top of the sai.git tree.
This fix will then be ported to 1.8.1 and 1.8.2 will be released.

This patch
===========

Towards that end, this diff fixes saiacl.h.

Specifically, below patch was first introduced in v1.7.0 and inserted enum fields 'in betweeen':
1aeb1c8

Thus,

- In 1.6.5: SAI_ACL_ENTRY_ATTR_FIELD_DSCP is 4126, SAI_ACL_ENTRY_ATTR_ACTION_SET_DSCP is 8214 etc.
- In 1.8.1: SAI_ACL_ENTRY_ATTR_FIELD_DSCP is 4134, SAI_ACL_ENTRY_ATTR_ACTION_SET_DSCP is 8216 etc.

If the application created ACL entry with SAI_ACL_ENTRY_ATTR_FIELD_DSCP
(4126) prior to warmboot, even after warmboot, a get query on that ACL
entry returns 4126 which no longer means SAI_ACL_ENTRY_ATTR_FIELD_DSCP.

This patch fixes it by assigning explicit integer values, and thus
SAI_ACL_ENTRY_ATTR_FIELD_DSCP continues to be 4126 in newer SAI specs as
well.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>

* Assign explicit integer values to Hash enum fields

Problem
========

Consider a scenario where an application (adapter host) using SAI spec X
(say) warmboots to an application using new SAI spec Y (say).

If an enum is extended between X and Y with fields inserted "in between"
rather than "at the end" of the enum, the old fields can get "renumbered".
However, the SAI implementation (adapter) continues to return old enums
for previously returned objects thereby breaking the warmboot.

Possible approaches
===================

We discussed this during June 24, 2021 weekly SAI meeting and observed:

- This can e avoided by mandating that any new inserts to an enum will be
"at the end" (this could mean at the end of _END block). This will keep
the enum field values the same.
- However, that will come at the cost of readability: newly added fields
may be related to existing fields and thus for readability, those fields
belong togeter. Adding those to the end scatters the related fields
across the enum.

Solution
=========

Thus, we agreed to go with the below approach:
- Every enum field will have an explicit integer value assigned to it.
- Insertions can be "in between" (maintains readability) but the next
available unused integer value would be used for the new insertions.
- Thus, once an integer is assigned to an enum field, it does not change
with spec revision thereby not breaking warmboot.
- Between SAI spec 1.6.5 to 1.8.1, saihash.h and saiacl.h had new enms
inserted "in between".

Those will be "fixed" by assigning integer values to enum fields.

This fix will be applied to top of the sai.git tree.
This fix will then be ported to 1.8.1 and 1.8.2 will be released.

This patch
===========

Specifically, below patch was first introduced in v1.7.0 and inserted enum fields 'in betweeen':
21bdb48

- In 1.6.5: SAI_NATIVE_HASH_FIELD_L4_SRC_PORT is 7, SAI_NATIVE_HASH_FIELD_L4_DST_PORT is 8.
- In 1.8.1: SAI_NATIVE_HASH_FIELD_L4_SRC_PORT is 15, SAI_NATIVE_HASH_FIELD_L4_DST_PORT is 16.

If the application configured SAI_NATIVE_HASH_FIELD_L4_SRC_PORT (7)
prior to warmboot, even after warmboot, a query returns 7 which no
longer means SAI_NATIVE_HASH_FIELD_L4_SRC_PORT in 1.8.1.

This patch fixes it by assigning explicit integer values, and thus
SAI_NATIVE_HASH_FIELD_L4_SRC_PORT continues to be 7 in newer SAI specs
as well.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
shri-khare added a commit to shri-khare/SAI that referenced this pull request Jan 9, 2022
Assign values to sai_fdb_entry_attr_t enum fields

This patch:

opencomputeproject#1259 introduced
explicit numbering to enum fields to avoid breaking warmboot across SAI
spec enhancements while maintaining readability. It fixed saiacl.h and
saihash.h.

Introduce similar explicit numbering for enum sai_fdb_entry_attr_t.
Subsequent stacked commit needs to insert a new enum field in the
middle.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
shri-khare added a commit to shri-khare/SAI that referenced this pull request Jan 9, 2022
This stack is towards supporting FDB Source User Meta.

This patch:

opencomputeproject#1259 introduced
explicit numbering to enum fields to avoid breaking warmboot across SAI
spec enhancements while maintaining readability. It fixed saiacl.h and
saihash.h.

Introduce similar explicit numbering for enum sai_switch_attr_t
Subsequent stacked commit needs to insert a new enum field in the
middle.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
shri-khare added a commit to shri-khare/SAI that referenced this pull request Jan 9, 2022
This stack is towards supporting FDB Source User Meta.

This patch:

opencomputeproject#1259 introduced
explicit numbering to enum fields to avoid breaking warmboot across SAI
spec enhancements while maintaining readability. It fixed saiacl.h and
saihash.h.

Introduce similar explicit numbering for enum sai_switch_attr_t
Subsequent stacked commit needs to insert a new enum field in the
middle.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
shri-khare added a commit to shri-khare/SAI that referenced this pull request Jan 10, 2022
This stack is towards supporting FDB Source User Meta.

This patch:

opencomputeproject#1259 introduced
explicit numbering to enum fields to avoid breaking warmboot across SAI
spec enhancements while maintaining readability. It fixed saiacl.h and
saihash.h.

Introduce similar explicit numbering for enum sai_switch_attr_t
Subsequent stacked commit needs to insert a new enum field in the
middle.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
shri-khare added a commit to shri-khare/SAI that referenced this pull request Jan 10, 2022
This stack is towards supporting FDB Source User Meta.

This patch:

opencomputeproject#1259 introduced
explicit numbering to enum fields to avoid breaking warmboot across SAI
spec enhancements while maintaining readability. It fixed saiacl.h and
saihash.h.

Introduce similar explicit numbering for enum sai_switch_attr_t
Subsequent stacked commit needs to insert a new enum field in the
middle.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
shri-khare added a commit to shri-khare/SAI that referenced this pull request Jan 18, 2022
Assign values to sai_fdb_entry_attr_t enum fields

This patch:

opencomputeproject#1259 introduced
explicit numbering to enum fields to avoid breaking warmboot across SAI
spec enhancements while maintaining readability. It fixed saiacl.h and
saihash.h.

Introduce similar explicit numbering for enum sai_fdb_entry_attr_t.
Subsequent stacked commit needs to insert a new enum field in the
middle.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
shri-khare added a commit to shri-khare/SAI that referenced this pull request Jan 18, 2022
This stack is towards supporting FDB Source User Meta.

This patch:

opencomputeproject#1259 introduced
explicit numbering to enum fields to avoid breaking warmboot across SAI
spec enhancements while maintaining readability. It fixed saiacl.h and
saihash.h.

Introduce similar explicit numbering for enum sai_switch_attr_t
Subsequent stacked commit needs to insert a new enum field in the
middle.

Signed-off-by: Shrikrishna Khare <skhare@fb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants