From fdd642c77f9733136c63e88a354e223e12784258 Mon Sep 17 00:00:00 2001 From: Junhua Zhai Date: Tue, 20 Aug 2024 16:39:25 +0000 Subject: [PATCH] Fix spelling check error --- .wordlist.txt | 17 ++++++++++++++ .../dataplane/dash-bmv2-data-plane-app.md | 22 +++++++++++++------ 2 files changed, 32 insertions(+), 7 deletions(-) diff --git a/.wordlist.txt b/.wordlist.txt index 44ec48bb5..19462aaf8 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -100,6 +100,8 @@ configs Conntrack Containerlab CP +cpus +CPUs CreatedHalfOpenFlow CreatedOtherFlow CreatedTcpFlow @@ -120,6 +122,7 @@ CurrentUdpFlow customizable Cx cyberithub +dashsai dashsubmodule DASHOrch dashorch @@ -146,6 +149,8 @@ decap'ing decaps deliverables DemoDays +dequeue +dequeues designator DEST dest @@ -171,6 +176,8 @@ dockerized DoS DotNet downcasting +dpapp +DPAPP DPDK DPU dpu @@ -215,11 +222,14 @@ eni Eni ENIs ENI's +enqueue +enqueues entrypoints enum EPUs EPYC ethernet +EtherType executables ExpressRoute extern @@ -229,6 +239,7 @@ failovers fakesai FastPath fc +FDio FEC ffe FINPackets @@ -315,6 +326,7 @@ Jinja jitter journaled json +Junhua keepalive keepalives Keysight @@ -507,6 +519,7 @@ routable RPC RPCs RPF +RSS RST RSTPackets RSTs @@ -695,6 +708,9 @@ vport VPort vPORT VPorts +vpp +VPP +vppctl VTEP VTEPs VxLAN @@ -738,6 +754,7 @@ Gan Ze AppDBMemoryEstimation Ivantsiv +Zhai Zhixiong Niu validonly diff --git a/documentation/dataplane/dash-bmv2-data-plane-app.md b/documentation/dataplane/dash-bmv2-data-plane-app.md index cf7a3291a..c0c7d4854 100644 --- a/documentation/dataplane/dash-bmv2-data-plane-app.md +++ b/documentation/dataplane/dash-bmv2-data-plane-app.md @@ -54,7 +54,11 @@ In flow lookup stage, if packet hits one flow, it will refresh flow timestamp. D ### 3.2. HA - Inline flow replication
-In HA context, Active data-plane app creates flow, replicates the flow in metadata, glues it with original packet, and sends the packet to Standby data-plane app via DPU data-plane channel. Standby data-plane app recreates the flow, and acknowledges Active data-plane app to finish flow creation. The same logics apply for flow deletion, flow age-out. +In HA context, Active data-plane app creates flow, replicates the flow in +metadata, glues it with original packet, and sends the packet to Standby +data-plane app via DPU data-plane channel. Standby data-plane app recreates +the flow, and acknowledges Active data-plane app to finish flow creation. The +same logic can apply for flow deletion, flow age-out. - Flow bulk sync
Flow bulk sync replicates batch flows from one DPU to another to make flow table consistency on Active and Standby DPUs. When HA agents starts a bulk sync via DASH SAI, Active data-plane app will walk flow table based on sync method (perfect/range), generate batch flows and send them to Standby data-plane app with gRPC via control-plane channel. Standby date-plane app will create flows in order. @@ -71,7 +75,10 @@ Refer to [SONiC DASH HLD](https://github.com/sonic-net/DASH/blob/main/documentat Referring to the above figure, data-plane app overall is a multi-thread vpp application, running in a standalone container. It includes these components: - vpp master, it runs dashsai server to receive dashsai requests (dash object CRUD) via northbound RPC channel and then invoke DASH SAI APIs to handle them. The server also processes flow creation/deletion notification from vpp workers. -- vpp workers, they serve as an exception path of packet processing, running on multi-cpus. It creates a flow in local flow table and notifies dashsai server to offload it to BMv2 flow table. The packet is temporarily queued. After workers know the success of flow offloading to BMv2, they deque the packet and send it back to P4 pipeline via VPP port. The workers also do flow age-out task with proper scheduling. +- vpp workers, they serve as an exception path of packet processing, running +on multi-cpus. It creates a flow in local flow table and notifies dashsai +server to offload it to BMv2 flow table. The packet is temporarily queued. +After workers know the success of flow offloading to BMv2, they dequeue the packet and send it back to P4 pipeline via VPP port. The workers also do flow age-out task with proper scheduling. - flow table, is a local cache of BMv2 flow table. - DASH SAI, is a unique interface for DASH object CRUD of DASH pipeline, implemented by DASH BMv2. - VPP port, is a veth interface and connects to BMv2 via veth pair. It serves as datapath channel to receive/send all packets between date-plane app and BMv2. Generally the port supports multi RSS queues, each queue binds to one vpp worker. @@ -84,7 +91,7 @@ Referring to the below figure from [HA API HLD], it greatly outlines the whole p ![packet flow in data plane](https://github.com/sonic-net/DASH/blob/main/documentation/high-avail/images/ha-bm-packet-flow.svg) -From the perspective of DPAPP, its core task in slow path is to create flow in flow table in case of flow miss in Flow (ConnTrack) lookup stage, and then maintain flow state. The sub sections will depict these functions around flow object. +From the perspective of DPAPP, its core task in slow path is to create flow in flow table in case of flow miss in Flow (Conntrack) lookup stage, and then maintain flow state. The sub sections will depict these functions around flow object. ### 6.1. DASH metadata @@ -198,7 +205,8 @@ sequenceDiagram ``` ### 6.4. HA flow -Base on basic flow, HA flow adds an extra FLOW_SYNCED state, which involves extra sync req/response ping-pang between DPAPP and PEER DPAPP. +Base on basic flow, HA flow adds an extra FLOW_SYNCED state, which involves +extra sync for request/response ping-pang between DPAPP and PEER DPAPP. ### 6.5. HA flow resimulation Same as section 6.3, but also do the below: @@ -244,7 +252,7 @@ The below table lists all test cases, all of which must be scripted based on DAS
  • dashsai client sends request for DASH SAI objects CRUD
  • Verify dashsai server handles them correctly
  • Verify dashsai server calls proper DASH SAI APIs
    • -
  • Verify dashsai server replys dashsai client
    • +
  • Verify dashsai server replies dashsai client
    • @@ -295,13 +303,13 @@ The below table lists all test cases, all of which must be scripted based on DAS
    1. Same test steps as test case 1.2
    2. Update outbound CA->PA mapping via SAI
      3. -
    3. Verify underly DIP is changed in CA entry of table outbound_ca_to_pa
      4. +
    4. Verify underlay DIP is changed in CA entry of table outbound_ca_to_pa
    5. Get flow attr UNDERLAY_DIP via SAI flow get
    6. Verify the above attr value unchanged
    7. Send TCP DATA packet
    8. Get flow attr UNDERLAY_DIP again via SAI flow get
    9. Verify the attr value changed to new PA
      10. -
    10. Triger multiple flows of one eni
      11. +
    11. Trigger multiple flows of one eni
    12. Set eni attr FULL_RESIMULATION_REQ via SAI