-
Notifications
You must be signed in to change notification settings - Fork 539
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
Implementation of System ports initialization, Interface & Neighbor Synchronization... #1431
Conversation
Signed-off-by: vedganes <[email protected]>
Signed-off-by: vedganes <[email protected]>
Signed-off-by: vedganes <[email protected]>
Signed-off-by: vedganes <[email protected]>
Signed-off-by: vedganes <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As comments for NeighOrch
Signed-off-by: vedganes <[email protected]>
Signed-off-by: vedganes <[email protected]> Kernel programming of static neigh and full mask static route for system neighbors is moved to nbrmgr since orchagent should not own kernel objects to avoid complication in warmboot reconciliation The orchagent programms only SAI object for the system neighbors and signals the completion of SAI programming by setting mac address in SYSTE_NEIGH table of STATE_DB. Nbrmgr subscribes to these state entries to program kernel entries corresponding to the system neighs
This code is to add support for fabric asic or NPU with fabric port enabled. What it does includes: 1. Create FabricOrchDaemon for fabric asic 2. Create FabricPortsOrch to manage fabric ports 3. Fabric port and queue stats are collected via FlexCounters The code is waiting for sonic-net#1431 to start fabric flow for fabric asic or NPU with enabled fabric ports.
vs test fails because of sonic-sairedis PR sonic-net/sonic-sairedis#737, which introduced the fabric port creation in voq switch create. It seems we create fabric port for both NPU asic and fabric asic. But in this PR #1431 we do not have support to supply fabric port lane mapping in line cards in vs tests (test_virtual_chassis.py). Without fabriclanemap.ini info switch create fails and orchagent crashes. To fix this: @lguohan, @ngoc-do, @eswaranb any other suggestions to address this? |
Oh, that's right. Sorry, sonic-net/sonic-sairedis#737 is blocking you now. Yes, to fix it, seems option 2 is faster for you. I made this sonic-net/sonic-sairedis#769. Hope it will remove the blocker. Of course, we won't merge sonic-net/sonic-buildimage#6185 until this PR merges. |
Fix vstest lib for sonic-net/sonic-swss#1431. Signed-off-by: ngocdo <[email protected]>
retest vs please |
1 similar comment
retest vs please |
Thanks for fixing |
This code is to add support for fabric asic or NPU with fabric port enabled. What it does includes: 1. Create FabricOrchDaemon for fabric asic 2. Create FabricPortsOrch to manage fabric ports 3. Fabric port and queue stats are collected via FlexCounters The code is waiting for sonic-net#1431 to start fabric flow for fabric asic or NPU with enabled fabric ports.
…ynchronization... (sonic-net#1431) This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Dependency PR's (sonic-swss-common): sonic-net/sonic-swss-common#380 (sonic-sairedis): sonic-net/sonic-sairedis#657 * [voq] Redis instance for global app db * [voq] System port init and orchestration * [voq] Router interface for system ports, global app db sync * [voq] Inband interface config * [voq] System port neighbors Kernel programming of static neigh and full mask static route for system neighbors is moved to nbrmgr since orchagent should not own kernel objects to avoid complication in warmboot reconciliation The orchagent programs only SAI object for the system neighbors and signals the completion of SAI programming by setting mac address in SYSTE_NEIGH table of STATE_DB. Nbrmgr subscribes to these state entries to program kernel entries corresponding to the system neighs * [swss]VS tests for VOQ system ports The following tests are added as part of virtual chassis tests - VOQ switch objects verification - System port object syncing with chassis app db by checking presence of system port RIFs in chassis app db in supervisor card - Creation of system port RIF record creation in ASIC_DB Following changes are done for the above tests: - SYSTEM_PORT table is added in default_config.json of line cards. These are loaded as part of config_db loading - Core and Port index mapping file is added in line card directories. - use dvs_database.py lib to connect to redis databases instead of using raw connection via swsscommon DBConnectors. - call dvs apis to get access to databases for the local redis instances. - Default handling for speed of the system port is removed in addSystemPorts() - Comment added to clarify types of rif-s synced to chassis app db - vs tests: connection to chassis app dp uses chassis app db id defined in dvs lib instead of using the id from swsscommon Using the chassis app db id from swsscommon instead of chassis app db id from dvd lib . This is to avoid python lgtm alert and test failure. Co-authored-by: vedganes <[email protected]> Co-authored-by: vganesan-nokia <[email protected]>
This code is to add support for fabric asic or NPU with fabric port enabled. What it does includes: 1. Create FabricOrchDaemon for fabric asic 2. Create FabricPortsOrch to manage fabric ports 3. Fabric port and queue stats are collected via FlexCounters The code is waiting for sonic-net#1431 to start fabric flow for fabric asic or NPU with enabled fabric ports.
This code is to add support for fabric asic or NPU with fabric port enabled. What it does includes: 1. Create FabricOrchDaemon for fabric asic 2. Create FabricPortsOrch to manage fabric ports 3. Fabric port and queue stats are collected via FlexCounters The code is waiting for sonic-net#1431 to start fabric flow for fabric asic or NPU with enabled fabric ports.
…ynchronization... (sonic-net#1431) This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration. HLD: sonic-net/SONiC#639 Dependency PR's (sonic-swss-common): sonic-net/sonic-swss-common#380 (sonic-sairedis): sonic-net/sonic-sairedis#657 * [voq] Redis instance for global app db * [voq] System port init and orchestration * [voq] Router interface for system ports, global app db sync * [voq] Inband interface config * [voq] System port neighbors Kernel programming of static neigh and full mask static route for system neighbors is moved to nbrmgr since orchagent should not own kernel objects to avoid complication in warmboot reconciliation The orchagent programs only SAI object for the system neighbors and signals the completion of SAI programming by setting mac address in SYSTE_NEIGH table of STATE_DB. Nbrmgr subscribes to these state entries to program kernel entries corresponding to the system neighs * [swss]VS tests for VOQ system ports The following tests are added as part of virtual chassis tests - VOQ switch objects verification - System port object syncing with chassis app db by checking presence of system port RIFs in chassis app db in supervisor card - Creation of system port RIF record creation in ASIC_DB Following changes are done for the above tests: - SYSTEM_PORT table is added in default_config.json of line cards. These are loaded as part of config_db loading - Core and Port index mapping file is added in line card directories. - use dvs_database.py lib to connect to redis databases instead of using raw connection via swsscommon DBConnectors. - call dvs apis to get access to databases for the local redis instances. - Default handling for speed of the system port is removed in addSystemPorts() - Comment added to clarify types of rif-s synced to chassis app db - vs tests: connection to chassis app dp uses chassis app db id defined in dvs lib instead of using the id from swsscommon Using the chassis app db id from swsscommon instead of chassis app db id from dvd lib . This is to avoid python lgtm alert and test failure. Co-authored-by: vedganes <[email protected]> Co-authored-by: vganesan-nokia <[email protected]>
…ins (sonic-net#1431) #### What I did Config files do not belong under `<platform>/plugins/` directory. That directory is intended for (now-deprecated) platform-related Python plugins. The directory will be removed in the near future. #### How I did it Look for udevprefix.conf file directly under the respective platform directory instead. Also clean up and reorganize imports NOTE: When this submodule is updated in sonic-buildimage, related files will need to be updated. Currently only platform/broadcom/sonic-platform-modules-cel/haliburton/script/udev_prefix.sh
Fix vstest lib for sonic-net/sonic-swss#1431. Signed-off-by: ngocdo <[email protected]>
This PR includes implementation of System ports initialization & orchestration, Interface & Neighbor Synchronization using GLOBAL_APP_DB, Inband Interface Configuration.
HLD: sonic-net/SONiC#639
Dependency PR's
(sonic-swss-common): sonic-net/sonic-swss-common#380
(sonic-sairedis): sonic-net/sonic-sairedis#657