Keysight AI DCB collective communications - #491
Conversation
Snapshot of Keysight's model work, from internal commit 5a19c55eb586, based on upstream c48c7ea. Generated artifacts are built by CI from the sources in this commit. Co-authored-by: crisdinu <cristian-mircea.dinu@keysight.com> Co-authored-by: Cristian Dinu <cristian-mircea.dinu@keysight.com> Co-authored-by: lyle <lyle.thompson@keysight.com> Co-authored-by: Lyle Thompson <lyle.thompson@keysight.com> Co-authored-by: lythomps <lyle.thompson@keysight.com> Co-authored-by: simosnid <simon.snider@keysight.com>
| description: >- | ||
| Selects a system-provided or custom collective algorithm. | ||
| x-field-uid: 1 | ||
| flow_control_config: |
There was a problem hiding this comment.
Not sure if flow_control_config really depend on which algorithm is chosen. Would it make more sense to make it a sibling of collective_algorithm and transport instead of nested inside Algorithm?
| RoCEv2 transport settings. | ||
| x-field-uid: 2 | ||
|
|
||
| CollectiveCommunication.Rocev2TransportSettings: |
There was a problem hiding this comment.
For a dual-stack device, how to specify the IP version for the Rocev2?
There was a problem hiding this comment.
So, the otg rocev2 device settings define a list of IPv4 peers and a list of IPv6 peers. Each of those peers has the name of an otg ipv4 or ipv6 device (that is defined on the ipv4_interfaces and/or ipv6_interfaces of an ethernets device). The nic bindings have the name of the otg ethernets device, which can have both ipv4 and ipv6 devices. If the transport is rocev2, then it uses the rocev2 peer wired up to the named tcp device on that ethernets device. Otherwise, if it's a tcp transport, then it uses the ethernet.ipv4/ipv6_interfaces directly.
Here's an ascii diagram:
dual_stack_otg.txt
It's a bit complicated, but this is the "otg way"
| type: string | ||
| default: reliable_connection | ||
| x-enum: | ||
| reliable_connection: |
There was a problem hiding this comment.
There are two separate places that specify the connection type — Rocev2.ConnectionType in device/rocev2/qps.yaml (per-QP) and Rocev2.QPConnectionType in port/rocev2.yaml (per-port) — what happens if they're configured differently? Also, is there a plan to add other connection types (e.g. unreliable_datagram) to either of them?
There was a problem hiding this comment.
The port values are overrides. In other words the connection type in port/rocev2 overrides the value in device/rocev2 for the specified ports. Any unlisted ports get the value from device/rocev2.
| type: integer | ||
| format: uint64 | ||
| x-field-uid: 4 | ||
| completion_time: |
There was a problem hiding this comment.
What is the difference between completion_time and total_time in CollectiveCommunications.SingleCollective.Summary.Metric.
Since total_time covers all iterations, is completion_time meant to be the average per-iteration time?
| properties: | ||
| choice: | ||
| type: string | ||
| default: reliable_connection |
There was a problem hiding this comment.
This slipped through. We must not change the existing OTG definitions (adding to them with defaultable fields is ok).
Snapshot of Keysight's model work, from internal commit 5a19c55eb586, based on upstream c48c7ea. Generated artifacts are built by CI from the sources in this commit.
Feature Overview
Add support for benchmarking collective communications systems
Feature Details
config body: /collective_communications
config body: /artifacts
set_control_state body: /collective_communications
get_state body: /collective_communications
get_metrics body: /collective_communications
new api: generate_config
Code snippets