[linux-cp/dpdk] Fix sub-port and LAG sub-port datapath on sonic-platform-vpp

[lunyue-ms]

Description

Description of PR

Summary:
Three platform-level fixes that, together with the companion
sonic-sairedis PR, restore the sub-port and LAG-sub-port datapath
on sonic-platform-vpp. After this PR, PTF
test_sub_port_interfaces.py::TestSubPorts::test_packet_routed_with_valid_vlan
passes on vlab-vpp-01 for both [port] and [port_in_lag]
parametrisations.

Fixes: sonic-net/sonic-platform-vpp#227

Companion PR:

• [vslib/vpp] Fix sub-port and LAG sub-port datapath on SONiC-VPP platform sonic-sairedis#1907 (must be merged together to reproduce
  the PASS result)

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation update
• Test improvement

Approach

What is the motivation for this PR?

On sonic-platform-vpp, three independent issues keep the sub-port
datapath broken: VPP linux-cp holds the sub-port host netdev DOWN after
each itf-pair (re)create, DPDK virtio ports come up non-promiscuous and
drop broadcast ARP on freshly-created L3 sub-ports, and
lcp-auto-subint races sairedis to install the LAG sub-port LCP pair
(producing the wrong host tap). Together with the companion sairedis
changes, fixing these three restores sub-port and LAG sub-port
datapath end-to-end.

How did you do it?

Changes are confined to docker-syncd-vpp / docker-sonic-vpp config
and docs/HLD/:

1. lcp-sync enabled — VPP propagates sub-interface admin state to
   the host tap; without it linux-cp keeps the host netdev DOWN after
   itf-pair (re)create, even if IntfMgr already ran ip link set up.
2. DPDK promisc reconciler — dedicated supervisord program
   vpp_promisc.sh polls for DPDK port appearance and runs
   vppctl set interface promiscuous on bobm*. Real ASICs are
   implicitly promiscuous on routed ports; VPP's startup-config
   directive cannot fix this because it runs before the DPDK plugin
   initialises ports.
3. lcp-auto-subint disabled — sairedis is now the sole producer
   of sub-port LCP pairs and atomically wires up
   configure_lcp_interface(BondEthernet<id>.<vlan>, be<id>.<vlan>)
   plus the bidirectional tc mirred bridge between be<id>.<vlan>
   and the SONiC L3 netdev PortChannel<id>.<vlan> in the same SAI
   RIF create.
4. Promisc reconciler hardening — phase-1 timeout exits 0 with
   autorestart=unexpected (no respawn storm on virtio-only platforms),
   and a whitespace-tolerant regex avoids re-issuing
   set promiscuous on every 2s on minor VPP output format changes.
5. HLD docs — vpp-lag.md gains a new "LAG Subinterface" section
   describing the 3-tuple naming (PortChannel<id>.<vlan> /
   BondEthernet<id>.<vlan> / be<id>.<vlan>) and the bidirectional
   tc mirred bridge; SONICVPP-HLD.md adds a LAG Subinterface row
   to the "Interface Create Flow by Type" table.

How did you verify/test it?

Result: 22 passed / 10 failed in ~32 min.

Failure breakdown:

• 6 upstream-blocked, out of this PR's scope:
  • SVI variants (×2): test_routing_between_sub_ports_and_port[*-svi]
    — blocked by VLAN BVI / SVI routing not implemented in vslib/vpp
    (sonic-buildimage #26936).
  • IPinIP variants (×4): test_tunneling_between_sub_ports[*]
    — blocked by sairedis PR #1860 (IPinIP encap/decap; VPP 2510 enum
    needs MP2P->MP alias).
• 4 LAG-sub-port follow-up, also out of scope:
  test_routing_between_sub_ports_and_port[port_in_lag-l3],
  test_routing_between_sub_ports_unaffected_by_sub_ports_removal[port_in_lag-different],
  test_balancing_sub_ports[port_in_lag],
  test_max_numbers_of_sub_ports[port_in_lag].
  DUT-originated ARP on a LAG sub-port can still fail to install a
  neighbor into the VPP sub-interface RIF in these stress / cross-port
  cases. The [port] counterparts PASS in the same run, isolating the
  bug to the LAG-specific plumbing (tc bridge or kernel → VPP
  propagation on top of it). Tracked as a follow-up PR.

Any platform specific information?

Changes only touch sonic-platform-vpp (docker-syncd-vpp /
docker-sonic-vpp config + HLD). No impact on other ASIC platforms.
Both syncd and sonic images are updated symmetrically. The companion
sonic-sairedis PR is required to reproduce the PASS result.

Documentation

Updated docs/HLD/vpp-lag.md (new "LAG Subinterface" section, v0.3
revision, status row) and docs/HLD/SONICVPP-HLD.md (Subinterface row
aligned with current behaviour; new LAG Subinterface row).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yue-fred-gao]

I am not sure about this. vpp has api to do that. in vlan-bvi HLD (#228), it has this.

4.7 Promiscuous Mode on Every Physical Interface

File: SwitchVppHostif.cpp

At LCP pair creation for each physical port:

configure_lcp_interface(hwif_name, dev, true);
interface_set_promiscuous(hwif_name, true);  // <-- added

[lunyue-ms]

Good idea. interface_set_promiscuous() is listed in HLD #228 but isn't in master yet — the underlying VPP API sw_interface_set_promisc exists, so it's a thin shim.

I'll add it into sairedis PR #1907: add the wrapper, call it from SwitchVppHostif::createHostif after configure_lcp_interface(), and remove vpp_promisc.sh from this PR. Do you agree?

[yue-fred-gao]

If we disable it, vpp sai needs to create sub interface for regular Ethernet interface. Is this in the plan?

[lunyue-ms]

In sonic-net/sonic-sairedis#1907, In SwitchVppRif.cpp::vpp_create_router_interface():
int ret = create_sub_interface(parent_hwif, vlan_id, vlan_id);
if (ret != 0) { return SAI_STATUS_FAILURE; }

 ret = configure_lcp_interface(hw_subifname, lcp_host, true);
 if (ret != 0) {
     delete_sub_interface(parent_hwif, vlan_id);   // rollback
     return SAI_STATUS_FAILURE;
 }

For a regular Ethernet sub-port (e.g. Ethernet0.10) this will be:
create_sub_interface("bobm0", 10, 10)
configure_lcp_interface("bobm0.10", "Ethernet0.10", true)

So I think that it covers to create sub interface for regular Ethernet interface.

[yue-fred-gao]

This is a big change. Please make sure you run full sonic-mgmt tests to avoid breakage

[lunyue-ms]

Yes, it is. I wil run a roll of ful regression tests to make sure it doesn't break any other tests.

[lunyue-ms]

Thanks @yue-fred-gao for your comments. Please check if my thoughts is feasible.

[lunyue-ms]

In sonic-net/sonic-sairedis#1907, In SwitchVppRif.cpp::vpp_create_router_interface():
int ret = create_sub_interface(parent_hwif, vlan_id, vlan_id);
if (ret != 0) { return SAI_STATUS_FAILURE; }

 ret = configure_lcp_interface(hw_subifname, lcp_host, true);
 if (ret != 0) {
     delete_sub_interface(parent_hwif, vlan_id);   // rollback
     return SAI_STATUS_FAILURE;
 }

For a regular Ethernet sub-port (e.g. Ethernet0.10) this will be:
create_sub_interface("bobm0", 10, 10)
configure_lcp_interface("bobm0.10", "Ethernet0.10", true)

So I think that it covers to create sub interface for regular Ethernet interface.

[lunyue-ms]

Yes, it is. I wil run a roll of ful regression tests to make sure it doesn't break any other tests.

[lunyue-ms]

Good idea. interface_set_promiscuous() is listed in HLD #228 but isn't in master yet — the underlying VPP API sw_interface_set_promisc exists, so it's a thin shim.

I'll add it into sairedis PR #1907: add the wrapper, call it from SwitchVppHostif::createHostif after configure_lcp_interface(), and remove vpp_promisc.sh from this PR. Do you agree?

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).