Skip to content

Custom speed mode #469

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.

Sign up for GitHub

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

Open
dipendughosh-k wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Custom speed mode #469

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e05588c
OTG Model to support different speed modes
dipendughosh-k Feb 24, 2026
5124c34
Update auto generated content
actions-user Feb 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions artifacts/openapi.html
View file
Open in desktop

Large diffs are not rendered by default.

8 changes: 8 additions & 0 deletions artifacts/openapi.yaml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 4 additions & 0 deletions artifacts/otg.proto
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

7 changes: 7 additions & 0 deletions layer1/layer1.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,8 @@ components:
x-field-uid: 12
speed_800_gbps:
x-field-uid: 13
custom_speed:
x-field-uid: 14
media:
description: |-
Set the type of media for test interface if supported. When no media
Expand Down Expand Up @@ -107,6 +109,11 @@ components:
name:
x-include: ../common/common.yaml#/components/schemas/Named.Object/properties/name
x-field-uid: 10
custom_speed:

@apratimmukherjee apratimmukherjee Mar 17, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

description: >-
Vendor specific custom speed.
type: string
x-field-uid: 11
Layer1.AutoNegotiation:
description: |-
Configuration for auto negotiation settings
Expand Down