Open KrisNey-MSFT opened 1 year ago
As sections are added to SONiC-HLD we can refer to the latest from Prince
Discussed James' email of 2/1/2023 to go through and identify if P4 items are applicable.
Code base unmaintained, work may be 'nontrivial'.
Possibly go over in Behavioral Model meeting 2/2/2023?
Underlay MAC address needs to be added by underlay routing.
Complete underlay in bmv2, we do not have the SAI path in the behavioral model.
Can we assume this will be done in SmartSwitch?
Had to comment out 'underlay routing' in @ashutosh-agrawal 's test
No neighbor table, how will bmv2 select the correct MAC address
Don't want to generate SAI APIs from P4 code
Next-hop table was implemented to facilitate testing
Allow pre-defined SAI APIs along side of DASH generated code; write a backend handler to deal w/hard-coded SAI APIs (Chris)
Here is the convo re: the issue - the jist of what is needed is in the Title.
Chris: do you want to be able to send traffic from port1-port2 for underlay etc.
Volodymyr – Having if else in code for real HW and BMv2 would be confusing.
Marian – BMv2 could do GW to port. Volodymyr - full underlay support not required but enough to send and receive traffic.
Mukesh – MAC address aspect to be resolved. We can solve with basic SAI routing, but BMV2 implementation ignores and sends packet out on same interface. Test will still work with default route that is pointing to both interfaces. The ### gap is underlay mac address that was pushed needs to be updated. If we can plumb in MAC address using existing SAI API. We need P4 table updated just enough
Marian – agree MAC address portion is open
Vincent – Intel test cases document where routing lookup is done and MAC / port is needed
Marian – default routing works in BMv2 and specific IP destination is looked up and send to specific port does not work
Volodymyr – Real DPU we advertise real addresses. P4 needs an update to update MAC address and need Automatic way to implement libsai
Group – WE can add the simple routing with MAC address resolution to task list.
For Real HW with 2 ports is the requirement for packet to come in one port and go out on another ? Yes. Both ports have same cost and ECMP needed.
For DASH assume simple routing. There needs to be a model how we connect these 2 blocks of routing and DASH. Full routing with uplinks/downlinks is SmartSwitch use case.
Don’t need to support per router interface. List of attributes in DASH HLD needs to be implemented, router-interface and source MAC address should be of the switch. Destination should be resolved based on Nexthop and neighbor. LPM lookup will point to ECMP of both ports so it doesn’t matter.