-
Notifications
You must be signed in to change notification settings - Fork 94
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
Add Dash flow design #462
Add Dash flow design #462
Conversation
hi @zhixiongniu - do we need to get the spellcheck to pass? |
Hi I will update this PR soon. |
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.
See minor spelling errors
|
||
/* @brief Destination port */ | ||
sai_uint16_t dst_port; | ||
} sai_dash_ha_flow_tcp_udp_info_t; |
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.
Any particular reason to include "ha" in the name of this structure?
#### Remove flow table | ||
|
||
```c | ||
/* Finally, remove the flow table */ |
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.
Do you expect this API to actively remove all the entries from the HW before returning the status? The alternative is to do perform a lazy delete where the ENI will be marked with a drop status and we can let HW age-out the entries over time.
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.
@zhixiongniu , this is a very point. I believe an attribute to control the flow expiry will be awesome to add.
just found my comments from months back are not published..... orz. |
#### Remove flow table | ||
|
||
```c | ||
/* Finally, remove the flow table */ |
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.
@zhixiongniu , this is a very point. I believe an attribute to control the flow expiry will be awesome to add.
since the sides are actually covered in the HA design, so we can either update that slides if anything new, or remove it and reference the HA doc. @zhixiongniu |
@r12f Looks like this needs a spellcheck correction before merge |
thanks @r12f and @KrisNey-MSFT @ashutosh-agrawal @chrispsommers, I will provided a updated version when the P4 generated version API is ready. |
Signed-off-by: Zhixiong Niu <[email protected]>
Signed-off-by: Zhixiong Niu <[email protected]>
Signed-off-by: Zhixiong Niu <[email protected]>
Signed-off-by: Zhixiong Niu <[email protected]>
IpAddress src_ip = 2; // Source IP address | ||
IpAddress dst_ip = 3; // Destination IP address | ||
uint32 src_port = 4; // Source port | ||
uint32 dst_port = 5; // Destination port |
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.
Don't we need IP protocol here as well?
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.
Yes, we should have IP protocol.
Signed-off-by: Zhixiong Niu <[email protected]>
uint32 meter_class = 3; // SAI_FLOW_ENTRY_ATTR_METER_CLASS | ||
bool is_unidirectional_flow = 4; // SAI_FLOW_ENTRY_ATTR_IS_UNIDIRECTIONAL_FLOW | ||
uint32 underlay_vni = 5; // SAI_FLOW_ENTRY_ATTR_UNDERLAY_VNI | ||
IpAddress underlay_sip = 6; // Underlay source IP address |
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.
Should we use underlay0 and underlay1 to be consistent with the SAI_FLOW_ENTRY_ATTRs listed earlier in this document?
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.
Sure, I have changed these.
uint32 underlay_vni = 5; // SAI_FLOW_ENTRY_ATTR_UNDERLAY_VNI | ||
IpAddress underlay_sip = 6; // Underlay source IP address | ||
IpAddress underlay_dip = 7; // Underlay destination IP address | ||
MacAddress underlay_smac = 8; // Underlay source MAC address |
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.
Remove underlay_smac and dmac as discussed earlier.
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.
Thanks. I have changed these.
uint32_t attr_count = 3; | ||
sai_attribute_t attr_list[3]; | ||
attr_list[0].id = SAI_FLOW_TABLE_ATTR_DASH_FLOW_ENABLED_KEY; | ||
attr_list[0].value = SAI_DASH_FLOW_ENABLED_KEY_PROTOCOL | |
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.
Is eni_addr skipped here intentionally?
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.
No, I added SAI_DASH_FLOW_ENABLED_KEY_ENI_ADDR in the value.
Thanks!
Signed-off-by: Zhixiong Niu <[email protected]>
Thanks, revised all typos. |
Thanks. I have solved all types. |
SAI_DASH_FLOW_ENABLED_KEY_SRC_PORT = 1 << 5, | ||
|
||
SAI_DASH_FLOW_ENABLED_KEY_DST_PORT = 1 << 6, | ||
|
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.
In NAT scenario, SAI_DASH_FLOW_ENABLED_KEY_VNI is needed, would you please help add this field support? Thanks.
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.
Thanks, added.
* @brief Exact matched key dst_port | ||
*/ | ||
sai_uint16_t dst_port; | ||
|
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.
Would you please add sai_uint32_t vni; so that we can support VNI as a key in flow_entry? Thanks.
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.
Thanks, added.
SAI_DASH_FLOW_ENTRY_BULK_GET_SESSION_FILTER_KEY_FLOW_VERSION, | ||
|
||
SAI_DASH_FLOW_ENTRY_BULK_GET_SESSION_FILTER_KEY_AGED, | ||
|
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.
Would you please add SAI_DASH_FLOW_ENTRY_BULK_GET_SESSION_FILTER_KEY_VNI so that we can support VNI as a key in filter? Thanks.
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.
Thanks, added.
When a service intends to use DASH Flow SAI APIs, it should first establish a flow table via the `create_flow_table()` function. After the table creation, the programmer can add, delete, modify, or retrieve flow entries to/from the table. For instance, when DASH HA needs to perform bulk sync from the active DPU to the standby DPU, it should initially fetch the entry from the active DPU using `get_flow_entries`, then transmit the flow entries to the standby DPU via the control plane. The standby DPU subsequently calls `create_flow_entries()`to add entries to the corresponding flow table. | ||
|
||
These examples describe how to create a flow state table, and how to operate flow entries. | ||
|
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.
Would a simple programing flow chart helps before example code? For example, take HA as a use case.
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.
Hi Clark,
Thanks for your comments! I have added a figure for this and also updated the words.
Signed-off-by: Zhixiong Niu <[email protected]>
Signed-off-by: Zhixiong Niu <[email protected]>
```c | ||
sai_flow_entry_t flow_entry; | ||
flow_entry.flow_table_id = 0x112233; | ||
flow_entry.ip_proto = 6; |
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.
eni id seems to be missing here.
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.
LGTM
The sai_dash_flow_enabled_key_t is defined as follows: | ||
|
||
```c | ||
typedef enum _sai_dash_flow_enabled_key_t |
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.
The word "enabled" is redundant.
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.
this is actually intentional, so it will differ from the flow key, which usually refers to the struct that holds all the fields. using "enabled key" makes it much more clear to be a flag that indicates which key field should be enabled during flow matching.
| Attribute name | Type | Description | | ||
| ----------------------------------- | --------------- | ------------------------------------------------------------ | | ||
| SAI_FLOW_ENTRY_ATTR_VENDOR_METADATA | `sai_u8_list_t` | Vendor-specific metadata that can be attached to the flow entry for custom processing. | | ||
| SAI_FLOW_ENTRY_ATTR_FLOW_DATA_PB | `sai_u8_list_t` | The flow data protocol buffer enables high-efficiency creation, retrieval, and communication for a flow entry. | |
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.
I don't think it's a good idea to tie the transport to the SAI struct. Vendor should provide a raw data that can be consumed as is by the other side.
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.
i think this attribute "VENDOR_METADAT" didn't break the assumption of "Vendor should provide a raw data that can be consumed as is by the other side.", as this is basically a raw buffer, and we will pass it as it is without the internal knowledge. Do you mind to elaborate this concern a bit more?
Signed-off-by: Zhixiong Niu <[email protected]>
No description provided.