If ports are translated entities (e.g. the controller uses strings), then the watch port field on ActionProfileAction cannot be used, because it is of type int32.
There are a few options on how to deal with this.
Option 1. We could have the watch port field be of type bytes and use a byte string like we do for most other places. This would allow the controller to use port numbers (without translation), or translated port IDs (strings, or larger bitwidth).
To not be backwards incompatible, we might want to deprecate the watch field and introduce a new field that is used going forward.
Option 2. We could make a oneof, where there is both a int32 watch port field, as well as a string watch port field, where the string field is used for @p4runtime_translation(.., string) and the int32 field for everything else. If someone where to use bit<45> for ports, this would still not work, because neither string nor int32 can represent that.
What do people think? Option 1 seems cleaner to me.
If ports are translated entities (e.g. the controller uses strings), then the watch port field on
ActionProfileActioncannot be used, because it is of typeint32.There are a few options on how to deal with this.
Option 1. We could have the watch port field be of type bytes and use a byte string like we do for most other places. This would allow the controller to use port numbers (without translation), or translated port IDs (strings, or larger bitwidth).
To not be backwards incompatible, we might want to deprecate the watch field and introduce a new field that is used going forward.
Option 2. We could make a oneof, where there is both a
int32watch port field, as well as a string watch port field, where the string field is used for@p4runtime_translation(.., string)and theint32field for everything else. If someone where to usebit<45>for ports, this would still not work, because neitherstringnorint32can represent that.What do people think? Option 1 seems cleaner to me.
@konne88