Custom speed mode

[dipendughosh-k]

Feature Overview

• Only Speed can be modified and not Port Mode
• For the OTG based solution snappi-ixnetwork to work with IxNetwork we can set the primary speed(800G, 400G, 100G, 50G, etc) only but we are unable to set the port mode(High Stream, RoCE, etc).

---

Feature Details

• ReDocly: https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/open-traffic-generator/models/custom_speed_mode/artifacts/openapi.yaml&nocors#tag/Configuration/operation/set_config
• So from now whenever user wants to set a specific port mode for a particular speed mode, user needs to set layer1->speed as "custom_speed" and set the required speed in layer1->custom_speed.

---

Code snippets

# configure layer 1 properties
layer, = config.layer1.layer1(name='layer')
layer.port_names = [tx.name, rx.name]
layer.speed = layer.CUSTOM_SPEED
layer.custom_speed = "novusTwoByFiftyGigNonFanOutHighStream"

https://github.com/open-traffic-generator/snappi-ixnetwork/blob/custom_speed_mode/tests/custom_port_speed/test_custom_port_speed_1.py

---

[apratimmukherjee]

We seem to have 3 requirements / open PR/branches for mode in addition to speed as of now :

1. This PR ( for high-stream mode )
2. OTG Model to support different RoCE speed #400 ( RoCE attempt)
3. dcdd849 ( no PR but macsec modes in separate branch ) .
   Please check if the macsec mode approach in 3) can be extended to handle these requirements.
   i.e. speed remains as is. ( it is a problematic field since it neither has a default nor is it required , which means snappi does not know what to do with it if user does not explicitly set it but sets something else ) .
   Idea is not to bring in this problem for design of other l1 params into mode control. ( Not sure why it was done the way it was done ; dont have context on that ) .
   Note that snappi tends to fill in missing attribs in a object with a default value or 0 ( e.g. must do for grpc mode of configuration )

So mode semantics as discussed for macsec looks like ( need to decide as a team whether it handles all of these requirements ) :

1. A new attribute with choices
   a) mode_no_change as default -> i.e. clear specification that if some other attribute is modified at l1 , keep the mode of the card as the current mode it is operating in and dont try to change. ( default op today )
   b) possible mode_default -> Allows a test to revert test port to its default mode i.e. what you get if you just connect to the card first time after booting it up [ might be tricky to impl. not sure ] -> Might not be exposed initially but can have such an enum if it makes sense for some usecases. e.g. mixed set of cases in a regression where after macsec test we want to switch back to default mode for rest of tests maybe.
   c) actual modes e.g. roce , macsec128 . macsec256 or high_stream_mode . ( custom last choice if must needed)
   -> Expectation if this is explicitly set :
   Impl. checks if this is a valid mode for speed of card and for the underlying h/w -> return error if not.
   Impl. checks if current mode is same as this , then nothing more to be done.
   If current mode not same expected mode and is valid, must specify that impl, must reset port to that mode and then apply the set_config on the reset port after verifying that port mode has been switched else should return appropriate error. set_config should block until port switches correctly to expected mode alongwith other specified l1 properties if any.

Please discuss if this approach handles the requirements for additional mode setting needed for some advanced scenarios in addition to speed.
Important considerations:

1. All l1 properties such as speed should have some sort of default setting of no_change.
2. Important to understand whether multiple modes can be combined e.g. needs an array or not for any scenario.