diff --git a/.github/workflows/pipeline.yml b/.github/workflows/pipeline.yml index f48767f6..c477ec49 100644 --- a/.github/workflows/pipeline.yml +++ b/.github/workflows/pipeline.yml @@ -168,7 +168,7 @@ jobs: python -m pip install setuptools build wheel - name: Set up Go environment - uses: actions/setup-go@v4.1.0 + uses: actions/setup-go@v5.0.0 with: go-version: 'stable' diff --git a/clients/p4rt-ctl/p4rt-ctl.in b/clients/p4rt-ctl/p4rt-ctl.in index aa0b8de6..2646b1e2 100644 --- a/clients/p4rt-ctl/p4rt-ctl.in +++ b/clients/p4rt-ctl/p4rt-ctl.in @@ -78,6 +78,7 @@ for P4Runtime switches: add-meter-config SWITCH MTR_TBL MTR_FLOW add packet mod meter config table entry get-packet-mod-meter SWITCH MTR_TBL MTR_FLOW gets packet mod meter table entry get-direct-pkt-mod-meter SWITCH MTR_TBL MTR_FLOW gets direct packet mod meter table entry + del-meter-config SWITCH MTR_TBL MTR_FLOW delete packet mod meter config table entry """ def usage(): @@ -1898,7 +1899,7 @@ def p4ctl_get_direct_pkt_mod_meter_entry(client, bridge, tbl_name, flow): raise Exception("Cannot find direct_meter_entry field in entity") te = helper.buildTableEntry( - table_name=cnt_tbl_name, + table_name=tbl_name, match_fields=key ) @@ -1909,6 +1910,34 @@ def p4ctl_get_direct_pkt_mod_meter_entry(client, bridge, tbl_name, flow): if entity.direct_meter_entry.table_entry.table_id == ce.table_entry.table_id: print(_format_dme(entry.direct_meter_entry)) +@with_client +def p4ctl_del_meter_config(client, bridge, tbl_name, flow): + """ + del-meter-config SWITCH MTR_TBL MTR_FLOW + Example: + p4rt-ctl del-meter-config br0 my_control.meter1 "meter_id=2244878476,meter_index=10" + """ + p4info = client.get_p4info() + if not p4info: + raise Exception("cannot retrieve P4Info from device {}".format(bridge)) + + helper = P4InfoHelper(p4info) + entity = p4runtime_pb2.Entity() + ce = entity.meter_entry + + if ce is None: + raise Exception("Cannot find meter_entry field in entity") + + meter_id, index = parse_get_meter_flow(flow) + ce.index.index = int(index) + ce.meter_id = int(meter_id) + + update = p4runtime_pb2.Update() + update.type = p4runtime_pb2.Update.DELETE + update.entity.meter_entry.CopyFrom(ce) + + client.write_update(update) + all_commands = { "show": (p4ctl_show, 1), "set-pipe": (p4ctl_set_pipe, 3), @@ -1933,6 +1962,7 @@ all_commands = { "add-meter-config" : (p4ctl_add_meter_config, 3), "get-packet-mod-meter" : (p4ctl_get_packet_mod_meter_entry, 2), "get-direct-pkt-mod-meter" : (p4ctl_get_direct_pkt_mod_meter_entry, 2) + "del-meter-config" : (p4ctl_del_meter_config, 2) } diff --git a/docs/apps/apps-index.rst b/docs/apps/apps-index.rst index 3b9ad246..68e7adec 100644 --- a/docs/apps/apps-index.rst +++ b/docs/apps/apps-index.rst @@ -6,4 +6,5 @@ ipsec-offload lnw/lnw-index + packet-io \ No newline at end of file diff --git a/docs/apps/ipsec-offload.md b/docs/apps/ipsec-offload.md index 4f3df7cc..e230ca72 100644 --- a/docs/apps/ipsec-offload.md +++ b/docs/apps/ipsec-offload.md @@ -44,10 +44,10 @@ to load the hardware FXP pipeline with the IPsec package. ### Configure and run infrap4d -To be able to program Security Association Database (SAD) entries using gNMI, -enable fixed function support in infrap4d. Follow the instructions in +Follow the instructions in [Running infrap4d](/guides/es2k/running-infrap4d.md) -to prepare system with generated TDI.json and context.json file references. +and prepare the system with generated TDI.json and context.json file references. +In order to offload IPsec, fixed function support must be enabled in infrap4d. The /usr/share/stratum/es2k/es2k_skip_p4.conf file must include the fixed function configuration reference. @@ -82,7 +82,7 @@ between local and peer system. This section provides detailed information on OpenConfig model and gNMI messages with the expected format. The strongSwan plugin has the following -details encoded. +details encoded, and user interaction is not needed. ### Config SAD message @@ -130,10 +130,10 @@ at `/ipsec-offload/ipsec-spi/rx-spi`. ### Key Expiry Notification message The [gRPC Notification message](https://github.com/ipdk-io/openconfig-public/blob/master/release/models/ipsec/openconfig-ipsec-offload.yang#L308) -at `/ipsec-offload` is used as a signal to trigger the +at `/ipsec-offload/sadb-expire` is used as a signal to trigger the re-keying mechanism in IKE protocol. A gNMI subscription stream is opened from the gNMI client listening to these notification messages originating in the target. Upon receiving this -notification, clients will initiate the re-keying mechanism to refresh -the encyrption keys. +notification, client will initiate the re-keying mechanism to refresh +the encryption keys. diff --git a/docs/apps/lnw/es2k/es2k-linux-networking-lag.md b/docs/apps/lnw/es2k/es2k-linux-networking-lag.md new file mode 100644 index 00000000..671dc31e --- /dev/null +++ b/docs/apps/lnw/es2k/es2k-linux-networking-lag.md @@ -0,0 +1,316 @@ +# Linux Networking with LAG (ES2K) + +This document explains how to run the Linux networking scenario with LAG (Link Aggregation Group) on ES2K. + +## Topology + +![Linux Networking Topology](es2k-ecmp-topology.png) + +Notes about topology: + +- Four Kernel netdevs are created by default by loading IDPF driver during ACC bring-up. You can also create more than four netdevs. For that, we need to modify the `acc_apf` parameter under `num_default_vport` in `/etc/dpcp/cfg/cp_init.cfg` on IMC before starting `run_default_init_app`. +- In `/etc/dpcp/cfg/cp_init.cfg`, also change the default `sem_num_pages` to the value specified in `/opt/p4/p4sde/share/mev_reference_p4_files/linux_networking/README_P4_CP_NWS`. +- In `/etc/dpcp/cfg/cp_init.cfg`, also modify the default `allow_change_mac_address` value to true. +- vlan1, vlan2, .... vlanN created using Linux commands and are on top of an IDPF Netdev. These VLAN ports should be equal to number of VMs that are spawned. +- br-int and the VxLAN ports are created using the ovs-vsctl command. The VxLAN ports are attached to br-int using ovs-vsctl command. +- Both physical ports P0 and P1 should be B2B connected to the Link Partner device and LAG should be configured on both the devices with the associated ports as LAG members using ip link command. + +System under test will have the above topology running the networking recipe. Link Partner can have the networking recipe or legacy OvS or kernel VxLAN. See the [Limitations](#limitations) section before setting up the topology. + +## Create P4 artifacts and start Infrap4d process + +Use the Linux networking P4 program present in the `/opt/p4/p4sde/share/mev_reference_p4_files/linux_networking` directory for this scenario. +See [Running Infrap4d on Intel IPU E2100](/guides/es2k/running-infrap4d) for instructions on compiling the P4 program, bringing up the ACC, and running `infrap4d` on the ACC. + +## Create the topology + +The p4rt-ctl and ovs-vsctl utilities can be found in $P4CP_INSTALL/bin. + +### Set the forwarding pipeline + +Once the application is started, set the forwarding pipeline config using the P4Runtime Client (`p4rt-ctl`) set-pipe command: + +```bash +$P4CP_INSTALL/bin/p4rt-ctl set-pipe br0 $OUTPUT_DIR/linux_networking.pb.bin \ + $OUTPUT_DIR/linux_networking.p4info.txt +``` + +`linux_networking.pb.bin` and `linux_networking.p4info.txt` were created, along with other artifacts, when the P4 program was compiled. + +### Configure VSI group and add a netdev + +Use one of the IDPF netdevs on ACC to receive all control packets from overlay +VMs by assigning to a VSI group. VSI group 3 is dedicated for this configuration, +execute below devmem commands on IMC. + +```bash +# SEM_DIRECT_MAP_PGEN_CTRL: LSB 11-bit is for vsi which need to map into vsig +devmem 0x20292002a0 64 0x8000050000000008 + +# SEM_DIRECT_MAP_PGEN_DATA_VSI_GROUP : This will set vsi +# (set in SEM_DIRECT_MAP_PGEN_CTRL register LSB) into VSIG-3 +devmem 0x2029200388 64 0x3 + +# SEM_DIRECT_MAP_PGEN_CTRL: LSB 11-bit is for vsi which need to map into vsig +devmem 0x20292002a0 64 0xA000050000000008 +``` + +Note: Here VSI 8 has been used for receiving all control packets and added +to VSI group 3. This refers to HOST netdev VSIG 3 as per the topology +diagram. Modify this VSI based on your configuration. + +### Create overlay network + +Option 1: Create VFs on HOST and attach VMs to the created VFs. + +Example to create 4 VFs: echo 4 > /sys/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/sriov_numvfs + +```bash +# VM1 configuration +telnet +ip addr add 99.0.0.1/24 dev +ifconfig up + +# VM2 configuration +telnet +ip addr add 99.0.0.2/24 dev +ifconfig up +``` + +Option 2: Use kernel network namespaces. + +Move each VF to a network namespace and assign IP addresses: + +```bash +ip netns add VM0 +ip link set netns VM0 +ip netns exec VM0 ip addr add 99.0.0.1/24 dev +ip netns exec VM0 ifconfig up + +ip netns add VM1 +ip link set netns VM1 +ip netns exec VM1 ip addr add 99.0.0.2/24 dev +ip netns exec VM1 ifconfig up +``` + +### Start OvS as a separate process + +Legacy OvS is used as a control plane for source MAC learning of overlay VMs. OvS should be started as a seperate process. + +```bash +export RUN_OVS=/tmp +rm -rf $RUN_OVS/etc/openvswitch +rm -rf $RUN_OVS/var/run/openvswitch +mkdir -p $RUN_OVS/etc/openvswitch/ +mkdir -p $RUN_OVS/var/run/openvswitch + +ovsdb-tool create $RUN_OVS/etc/openvswitch/conf.db \ + /opt/p4/p4-cp-nws/share/openvswitch/vswitch.ovsschema + +ovsdb-server $RUN_OVS/etc/openvswitch/conf.db \ + --remote=punix:$RUN_OVS/var/run/openvswitch/db.sock \ + --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ + --pidfile=$RUN_OVS/var/run/openvswitch/ovsdb-server.pid \ + --unixctl=$RUN_OVS/var/run/openvswitch/ovsdb-server.ctl \ + --detach + +ovs-vswitchd --detach \ + --pidfile=$RUN_OVS/var/run/openvswitch/ovs-vswitchd.pid \ + --no-chdir unix:$RUN_OVS/var/run/openvswitch/db.sock \ + --unixctl=$RUN_OVS/var/run/openvswitch/ovs-vswitchd.ctl \ + --mlockall \ + --log-file=/tmp/ovs-vswitchd.log + +alias ovs-vsctl="ovs-vsctl --db unix:$RUN_OVS/var/run/openvswitch/db.sock" +ovs-vsctl set Open_vSwitch . other_config:n-revalidator-threads=1 +ovs-vsctl set Open_vSwitch . other_config:n-handler-threads=1 + +ovs-vsctl show +``` + +### Create VLAN representers + +We need to have a port representer for each VM that is spawned for the overlay network. +We create VLAN netdevs on top of the IDPF netdev that was assigned to VSI group 3 in the [Configure VSI Group](#configure-vsi-group-and-add-a-netdev) step. + +```bash +ip link add link name vlan1 type vlan id 1 +ip link add link name vlan2 type vlan id 2 +ifconfig vlan1 up +ifconfig vlan2 up +``` + +Note: Here the assumption is, we have created 2 overlay VMs and creating 2 port representers for those VMs. +Port representer should always be in the format: `lowercase string 'vlan'+'vlanID'` + +### Create integration bridge and add ports to the bridge + +Create OvS bridge, VxLAN tunnel and assign ports to the bridge. + +```bash +ovs-vsctl add-br br-int +ifconfig br-int up + +ovs-vsctl add-port br-int vlan1 +ovs-vsctl add-port br-int vlan2 +ifconfig vlan1 up +ifconfig vlan2 up + +ovs-vsctl add-port br-int vxlan1 -- set interface vxlan1 type=vxlan \ + options:local_ip=30.1.1.1 options:remote_ip=40.1.1.1 options:dst_port=4789 +``` + +Note: Here we are creating VxLAN tunnel with VNI 0. You can create any VNI for tunneling. + +### Configure rules for overlay control packets + +Configure rules to send overlay control packets from a VM to its respective port representers. + +The following configuration assumes that: + +- Overlay VF1 has a VSI value 14 +- Overlay VF2 has a VSI value 15 + +These VSI values can be checked with the `/usr/bin/cli_client -q -c` command +on IMC. This command provides VSI ID, Vport ID, and corresponding MAC +addresses for all: + +- IDPF netdevs on ACC +- VFs on HOST +- IDPF netdevs on HOST (if IDPF driver loaded by you on HOST) +- Netdevs on IMC + +```bash +# Rules for control packets coming from overlay VF (VSI-14). +# IPU will add a VLAN tag 1 and send to HOST1 (VSI-8). + +p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_host_to_ovs_and_ovs_to_wire_table \ + "vmeta.common.vsi=14,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.add_vlan_and_send_to_port(1,24)" +p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_host_to_ovs_table \ + "vmeta.common.vsi=14,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(24)" +p4rt-ctl add-entry br0 linux_networking_control.vlan_push_mod_table \ + "vmeta.common.mod_blob_ptr=1,action=linux_networking_control.vlan_push(1,0,1)" + +# Rules for control packets coming from overlay VF (VSI-15). +# IPU will add a VLAN tag 2 and send to HOST1 (VSI-8). + +p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_host_to_ovs_and_ovs_to_wire_table \ + "vmeta.common.vsi=15,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.add_vlan_and_send_to_port(2,24)" +p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_host_to_ovs_table \ + "vmeta.common.vsi=15,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(24)" +p4rt-ctl add-entry br0 linux_networking_control.vlan_push_mod_table \ + "vmeta.common.mod_blob_ptr=2,action=linux_networking_control.vlan_push(1,0,2)" + +# Rules for control packets coming from HOST1 (VSI-8). +# IPU will remove the VLAN tag 1 and send to overlay VF (VSI-14). + +p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_ovs_to_host_table \ + "vmeta.common.vsi=8,hdrs.dot1q_tag[vmeta.common.depth].hdr.vid=1,action=linux_networking_control.remove_vlan_and_send_to_port(1,30)" +p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_ovs_to_host_table \ + "vmeta.misc_internal.vm_to_vm_or_port_to_port[27:17]=14,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(30)" +p4rt-ctl add-entry br0 linux_networking_control.vlan_pop_mod_table \ + "vmeta.common.mod_blob_ptr=1,action=linux_networking_control.vlan_pop" + +# Rules for control packets coming from HOST1 (VSI-8). +# IPU will remove the VLAN tag 2 and send to overlay VF (VSI-15). + +p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_ovs_to_host_table \ + "vmeta.common.vsi=8,hdrs.dot1q_tag[vmeta.common.depth].hdr.vid=2,action=linux_networking_control.remove_vlan_and_send_to_port(2,31)" +p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_ovs_to_host_table \ + "vmeta.misc_internal.vm_to_vm_or_port_to_port[27:17]=15,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(31)" +p4rt-ctl add-entry br0 linux_networking_control.vlan_pop_mod_table \ + "vmeta.common.mod_blob_ptr=2,action=linux_networking_control.vlan_pop" +``` + +### Configure rules for underlay control packets + +Configure rules to send underlay control packets from IDPF netdev to physical port. + +Below configuration assumes + +- Underlay IDPF netdev has a VSI value 10 for first LAG member +- First physical port will have a port ID of 0 +- Underlay IDPF netdev has a VSI value 11 for second LAG member +- Second physical port will have a port ID of 1 + +```bash +# Configuration for control packets between physical port 0 to underlay IDPF netdev VSI-10 +p4rt-ctl add-entry br0 linux_networking_control.handle_rx_from_wire_to_ovs_table \ + "vmeta.common.port_id=0,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(26)" + +# Configuration for control packets between underlay IDPF netdev VSI-10 to physical port 0 +p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_host_to_ovs_and_ovs_to_wire_table \ + "vmeta.common.vsi=10,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(0)" + +# Configuration for control packets between physical port 1 to underlay IDPF netdev VSI-11 +p4rt-ctl add-entry br0 linux_networking_control.handle_rx_from_wire_to_ovs_table \ + "vmeta.common.port_id=1,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(27)" + +# Configuration for control packets between underlay IDPF netdev VSI-11 to physical port 1 +p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_host_to_ovs_and_ovs_to_wire_table \ + "vmeta.common.vsi=11,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(1)" +``` + +### LAG configuration + +Create a LAG interface and add 2 IDPF netdevs as LAG members in it. Assign IP to the LAG interface. + +The following configuration assumes that: + +- Underlay IDPF netdev has a VSI value 10 for first LAG member +- Underlay IDPF netdev has a VSI value 11 for second LAG member + +```bash +ip link add bond0 type bond miimon 100 mode active-backup +ip link set down +ip link set master bond0 +ip link set down +ip link set master bond0 +ip link set bond0 up +ifconfig bond0 40.1.1.1/24 up +ip route change 40.1.1.0/24 via 40.1.1.2 dev bond0 +``` + +Sample link partner underlay configuration. +Create a LAG interface and assign IP to the LAG interface +Assuming ens785f0np0 and ens785f1np1 ports are B2B connected to MEV. + +```bash +ip link add bond0 type bond miimon 100 mode active-backup +ip link set ens785f0np0 down +ip link set ens785f0np0 master bond0 +ip link set ens785f1np1 down +ip link set ens785f1np1 master bond0 +ip link set bond0 up +ifconfig bond0 40.1.1.2/24 up + +ip link add vxlan0 type vxlan id 0 dstport 4789 remote 40.1.1.1 local 40.1.1.2 dev bond0 +ip addr add 40.1.1.2/24 dev bond0 +ip addr add 99.0.0.3/24 dev vxlan0 +ip link set vxlan0 up +ip link set bond0 up +``` + +### Test the ping scenarios + +- Verify the underlay ping is working fine via the active path. +- Verify the overlay ping between VMs on same host is working fine via the active path. +- Note the active link by using the command "cat /proc/net/bonding/bond0" on both MEV host and LP device. +- Shut the active link on both MEV host and its peer Link Partner. +- Verify the switchover happened from active to backup interface. +- Verify both underlay and overlay ping are working fine and taking a backup path. + +## Limitations + +Current Linux Networking support for the networking recipe has following limitations: + +- All VLAN interfaces created on top of IDPF netdev, should always be in lowercase format "vlan+vlan_id" +Ex: vlan1, vlan2, vlan3 ... vlan4094. +- Set the pipeline before adding br-int port, vxlan0 port, and adding vlan ports to br-int bridge. +- VxLAN destination port should always be standard port. i.e., 4789. (limitation by P4 parser). +- We do not support any ofproto rules that would prevent FDB learning on OvS. +- VLAN-tagged packets are not supported. +- For VxLAN tunneled packets only IPv4-in-IPv4 is supported. +- LAG and ECMP are mutually exclusive. Both can't co-exist in the system configuration at the same time. +- LAG configuration done via bonding driver is supported and the supported mode in active-backup. +- Number of nexthop table entries cannot go beyond 8K, because nexthop table is now part of WCM block. diff --git a/docs/apps/lnw/es2k/es2k-linux-networking.md b/docs/apps/lnw/es2k/es2k-linux-networking.md index 304cd09c..d7f80e78 100644 --- a/docs/apps/lnw/es2k/es2k-linux-networking.md +++ b/docs/apps/lnw/es2k/es2k-linux-networking.md @@ -1,292 +1,306 @@ - - # Linux Networking for ES2K -This document explains how to run the Linux networking scenario on ES2K. +Linux Networking provides support for offloading various networking functions, such as L2 forwarding, L3 forwarding, ECMP, and VxLAN encapsulation and decapsulation intelligence to the IPU. This capability empowers overlay services to establish communication with endpoints through VxLAN tunnels, thereby extending the L2 segment across the underlay network. To achieve Linux networking support, we have enhanced OvS for overlay source MAC learning and VxLAN configurations, while relying on the kernel for underlay neighbor discovery, route management, and next-hop information. -## Topology +## Feature Overview -![Linux Networking Topology](es2k-lnw-topology.png) +This feature can run in two modes: -Notes about topology: +- Slow path: All packets must land on the control plane and only the control plane has the intelligence to forward the traffic. +- Fast path: Only first unknown traffic (both SMAC and DMAC) will be sent to the control plane and subsequent traffic should be forwarded by IPU E2100. -- Four Kernel netdevs are created by default by loading IDPF driver during ACC bring-up. You can also create more than Four netdevs. For that, we need to modify `acc_apf` parameter under `num_default_vport` in `/etc/dpcp/cfg/cp_init.cfg` on IMC before starting `run_default_init_app`. -- In `/etc/dpcp/cfg/cp_init.cfg` file also modify default `sem_num_pages` value to the value mentioned in `/opt/p4/p4sde/share/mev_reference_p4_files/linux_networking/README_P4_CP_NWS`. -- vlan1, vlan2, .... vlanN created using Linux commands and are on top of an IDPF Netdev. These VLAN ports should be equal to number of VM's that are spawned. -- br-int, VxLAN ports are created using ovs-vsctl command provided by the networking recipe and all the vlan ports are attached to br-int using ovs-vsctl command. +To enable this feature we have, -System under test will have above topology running the networking recipe. Link Partner can have the networking recipe or legacy OvS or kernel VxLAN. Note the [Limitations](#limitations) section before setting up the topology. +- `Infrap4d`: This process includes a p4runtime server. Calls TDI front end to program IPU E2100. +- `ovs-vswitchd`: This process is integrated with p4runtime intelligence and acts as a gRPC client. Programs IPU E2100 with control plane configuration and forwarding tables by communicating with gRPC server. +- `p4rt-ctl`: This python CLI includes a p4runtime client. Programs IPU E2100 with runtime rules by communicating with gRPC server. +- `Kernel stack`: All underlay related configurations are picked by `kernel monitor` thread via netlink events in `infrap4d` and these are programmed in IPU E2100 by calling TDI front end APIs. -## Create P4 artifacts and start Infrap4d process +## Topology -- Use Linux networking p4 program present in the directory `/opt/p4/p4sde/share/mev_reference_p4_files/linux_networking` for this scenario. -- See [Running Infrap4d on Intel IPU E2100](/guides/es2k/running-infrap4d) for compiling `P4 artifacts`, `bringing up ACC` and running `infrap4d` on ACC. +This topology breakdown and configuration assumes all VMs are spawned on HOST VFs and the control plane is running on ACC. -## Creating the topology +![Linux Networking Topology](es2k-lnw-topology.png) -The p4rt-ctl and ovs-vsctl utilities can be found in $P4CP_INSTALL/bin. +### Topology breakdown -### Set the forwarding pipeline +- Every VM spawned on top of a VF will have a corresponding port representor in ACC. +- Every physical port will have a corresponding port representor in ACC. +- Every physical port will have an uplink (APF netdev) in HOST and this uplink will have a corresponding port representor in ACC. +- All port representors are associated with an OvS bridge. +- For VxLAN egress traffic, the underlay port should be associated with a termination bridge. The IP address to reach the underlay network should be configured on this bridge. -Once the application is started, set the forwarding pipeline config using -P4Runtime Client `p4rt-ctl` set-pipe command +## Detailed Design -```bash -$P4CP_INSTALL/bin/p4rt-ctl set-pipe br0 $OUTPUT_DIR/linux_networking.pb.bin \ - $OUTPUT_DIR/linux_networking.p4info.txt -``` +### Slow path -Note: Assuming `linux_networking.pb.bin` and `linux_networking.p4info.txt` -along with other P4 artifacts are created as per the steps mentioned in previous section. +To enable slow path mode: -### Configure VSI Group and add a netdev +- Start the infrap4d process with the Kernel Monitor disabled. Command: `infrap4d -disable-krnlmon` +- Set environment variable `OVS_P4_OFFLOAD=false` before starting the `ovs-vswitchd` process. -Use one of the IPDF netdevs on ACC to receive all control packets from overlay -VM's by assigning to a VSI group. VSI group 3 is dedicated for this configuration, -execute below devmem commands on IMC. +In this mode, VMs are spawned on top of VFs and associated with their port representors. Also, physical ports are associated with their port representors. Configure the following tables to map these in IPU: -```bash -# SEM_DIRECT_MAP_PGEN_CTRL: LSB 11-bit is for vsi which need to map into vsig -devmem 0x20292002a0 64 0x8000050000000008 +```text +- rx_source_port +- tx_source_port_v4/tx_source_port_v6 +- tx_acc_vsi +- vsi_to_vsi_loopback +- source_port_to_pr_map +- rx_phy_port_to_pr_map +``` -# SEM_DIRECT_MAP_PGEN_DATA_VSI_GROUP : This will set vsi -# (set in SEM_DIRECT_MAP_PGEN_CTRL register LSB) into VSIG-3. -devmem 0x2029200388 64 0x3 +All port representors (PRs) in ACC should be associated with an OvS bridge. Configure table below to program the mapping between PRs and bridges in IPU: -# SEM_DIRECT_MAP_PGEN_CTRL: LSB 11-bit is for vsi which need to map into vsig -devmem 0x20292002a0 64 0xA000050000000008 +```text +- source_port_to_bridge_map ``` -Note: Here VSI 8 has been used for receiving all control packets and added to VSI group 3. This refers to HOST netdev VSIG 3 as per the topology diagram. Modify this VSI based on your configuration. +For egress VxLAN traffic, an OvS VxLAN port needs to be created in ACC with associated integration bridge that handles overlay traffic. Configure following tables to map these in IPU: -### Create Overlay network +```text +- rx_ipv4_tunnel_source_port/rx_ipv6_tunnel_source_port +- source_port_to_bridge_map +``` -Option 1: Create VF's on HOST and spawn VM's on top of those VF's. -Example to create 4 VF's: echo 4 > /sys/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/sriov_numvfs +Once these tables are configured refer to packet flow as mentioned below. -```bash -# VM1 configuration -telnet -ip addr add 99.0.0.1/24 dev -ifconfig up +#### For Tx -# VM2 configuration -telnet -ip addr add 99.0.0.2/24 dev -ifconfig up -``` +##### Egress traffic without VxLAN encapsulation -Option 2: If we are unable to spawn VM's on top of the VF's, we can leverage kernel network namespaces. -Move each VF to a network namespace and assign IP addresses: +Packets coming from overlay network: -```bash -ip netns add VM0 -ip link set netns VM0 -ip netns exec VM0 ip addr add 99.0.0.1/24 dev -ip netns exec VM0 ifconfig up +- Determine the source port of the packet based on which overlay VSI the packet has landed on. +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, find the PR associated with the bridge and forward the packet to the PR in ACC. +- OvS control plane receives the packet and forwards the packet to destined PR if MAC is already learnt, else floods the packet in the valid bridge found. +- Sample OvS config: -ip netns add VM1 -ip link set netns VM1 -ip netns exec VM1 ip addr add 99.0.0.2/24 dev -ip netns exec VM1 ifconfig up -``` + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ``` -### Start OvS as a separate process +##### Egress traffic with VxLAN encapsulation -Legacy OvS is used as a control plane for source MAC learning of overlay VM's. OvS should be started as a seperate process. +Packets coming from overlay network: -```bash -export RUN_OVS=/tmp -rm -rf $RUN_OVS/etc/openvswitch -rm -rf $RUN_OVS/var/run/openvswitch -mkdir -p $RUN_OVS/etc/openvswitch/ -mkdir -p $RUN_OVS/var/run/openvswitch +- Determine the source port of the packet based on which overlay VSI the packet has landed on. +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, find the PR associated with the bridge and forward the packet to the PR in ACC. +- OvS control plane receives the packet and forwards the packet to the destined VxLAN port if MAC is already learnt, else flood the packet in the valid bridge found. +- Once the packet reaches the VxLAN port, here the kernel checks the routing table to reach `remote_ip` that is configured for the OvS VxLAN tunnel. +- Underlay network to reach `remote_ip` is configured on a TEP termination bridge. The kernel resolves the ARP for underlay network. +- Once ARP is resolved, the kernel encapsulates the packet. It then forwards the packet to the PR of the physical port if the MAC is already learnt, or floods it to the TEP termination bridge if not. +- Sample OvS config: -ovsdb-tool create $RUN_OVS/etc/openvswitch/conf.db \ - /opt/p4/p4-cp-nws/share/openvswitch/vswitch.ovsschema + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ovs-vsctl add-br br-tep-termination + # Configure bridge with IP address to reach remote TEP + ovs-vsctl add-port br-tep-termination + ``` -ovsdb-server $RUN_OVS/etc/openvswitch/conf.db \ - --remote=punix:$RUN_OVS/var/run/openvswitch/db.sock \ - --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ - --pidfile=$RUN_OVS/var/run/openvswitch/ovsdb-server.pid \ - --unixctl=$RUN_OVS/var/run/openvswitch/ovsdb-server.ctl \ - --detach +#### For Rx -ovs-vswitchd --detach \ - --pidfile=$RUN_OVS/var/run/openvswitch/ovs-vswitchd.pid \ - --no-chdir unix:$RUN_OVS/var/run/openvswitch/db.sock \ - --unixctl=$RUN_OVS/var/run/openvswitch/ovs-vswitchd.ctl \ - --mlockall \ - --log-file=/tmp/ovs-vswitchd.log +##### Ingress traffic without VxLAN encapsulation -alias ovs-vsctl="ovs-vsctl --db unix:$RUN_OVS/var/run/openvswitch/db.sock" -ovs-vsctl set Open_vSwitch . other_config:n-revalidator-threads=1 -ovs-vsctl set Open_vSwitch . other_config:n-handler-threads=1 +If the packet coming from a remote machine to the physical port is not VxLAN encapsulated packet: -ovs-vsctl show -``` +- Determine the source port of the packet based on which physical port the packet has landed on. +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, find the PR associated with the bridge and forward the packet to the PR in ACC. +- OvS control plane receives the packet and forwards it to destined PR if MAC is already learnt, else floods the packet in the valid bridge found. +- Sample OvS config: -### Create VLAN representers + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ``` -For each VM that is spawned for overlay network we need to have a port representer. -We create VLAN netdevs on top of the IPDF netdev which is assigned to VSI group 3 in step-2 mentioned above. +##### Ingress traffic with VxLAN encapsulation -```bash -ip link add link name vlan1 type vlan id 1 -ip link add link name vlan2 type vlan id 2 -ifconfig vlan1 up -ifconfig vlan2 up -``` +If the packet coming from a remote machine to the physical port is VxLAN encapsulated packet: + +- Determine the source port of the packet based on which physical port the packet has landed on. +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, find the PR associated with the physical port and forward the packet to the PR in ACC. +- OvS control plane receives the packet on a TEP termination bridge, packet gets decapped and sent to VxLAN port. +- Since VxLAN port and overlay VMs PR are in the same bridge, if the overlay MAC is already learnt the packet will be forwarded to destined PR else packet will be flooded in the valid bridge found. +- Sample OvS config: -Note: Here the assumption is, we have created 2 overlay VM's and creating 2 port representers for those VM's. -Port representer should always be in the format: `lowercase string 'vlan'+'vlanID'` + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ovs-vsctl add-br br-tep-termination ## this bridge has IP to reach remote TEP + ovs-vsctl add-port br-tep-termination + ``` -### Create integration bridge and add ports to the bridge +### Fast path (when IPU forwards the packet) -Create OvS bridge, VxLAN tunnel and assign ports to the bridge. +To enable fast path mode: -```bash -ovs-vsctl add-br br-int -ifconfig br-int up +- Start the infrap4d process. Command: `infrap4d` +- Remove the environment variable `OVS_P4_OFFLOAD=false` before starting the `ovs-vswitchd` process. -ovs-vsctl add-port br-int vlan1 -ovs-vsctl add-port br-int vlan2 -ifconfig vlan1 up -ifconfig vlan2 up +In this mode, we need to associate VFs with the VMs and its port representors along with physical ports and its port representors. +Configure tables: -ovs-vsctl add-port br-int vxlan1 -- set interface vxlan1 type=vxlan \ - options:local_ip=40.1.1.1 options:remote_ip=40.1.1.2 options:dst_port=4789 +```text +- rx_source_port +- tx_source_port_v4/tx_source_port_v6 +- tx_acc_vsi +- vsi_to_vsi_loopback +- source_port_to_pr_map +- rx_phy_port_to_pr_map +- tx_lag_table ## This is a dummy LAG entry when we have underlay as Non LAG case. ``` -Note: Here we are creating VxLAN tunnel with VNI 0, you can create any VNI for tunneling. +Once OvS bridge is created and PR's are added to the OvS bridge, a unique bridge ID for the OvS bridge is created and creates a mapping between ACC PR's & OvS bridge. This mapping is programed in IPU E2100 with, -### Configure rules for overlay control packets +```text +- source_port_to_bridge_map +- vlan_push_mod_table ## If ACC PR is part of a VLAN +- vlan_pop_mod_table ## If ACC PR is part of a VLAN +``` -Configure rules to send overlay control packets from a VM to its respective port representers. +Once a VxLAN tunnel is created on a particular OvS bridge, we program IPU E2100 with, -Below configuration assumes +```text +- rx_ipv4_tunnel_source_port/rx_ipv6_tunnel_source_port +- vxlan_encap_mod_table/vxlan_encap_v6_mod_table +- vxlan_encap_vlan_pop_mod_table/vxlan_encap_v6_vlan_pop_mod_table ## If VxLAN is part of a VLAN +- vxlan_decap_mod_table +- vxlan_decap_and_push_vlan_mod_table ## If VxLAN is part of a VLAN +- ipv4_tunnel_term_table/ipv6_tunnel_term_table +``` -- Overlay VF1 has a VSI value 14 -- Overlay VF2 has a VSI value 15 +When the first packet (either Tx or Rx) reaches the IPU, since no rules are programmed, this packet will be sent to respective PR's. From PR's OvS learns the MAC address and control plane dynamically programs, -These VSI values can be checked with `/usr/bin/cli_client -q -c` command on IMC. This command provides VSI ID, Vport ID, and corresponding MAC addresses for all +```text +- l2_fwd_smac_table +- l2_fwd_tx_table +- l2_fwd_rx_table +- l2_to_tunnel_v4/l2_to_tunnel_v6 +``` -- IDPF netdevs on ACC -- VF's on HOST -- IDPF netdevs on HOST (if IDPF driver loaded by you on HOST) -- Netdevs on IMC +When underlay network is configured and underlay neighbor is learnt we dynamically program, -```bash -# Rules for control packets coming from overlay VF (VSI-14). -# IPU will add a VLAN tag 1 and send to HOST1 (VSI-8). +```text +- ipv4_table/ipv6_table +- nexthop_table +- neighbor_mod_table +``` -p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_host_to_ovs_and_ovs_to_wire_table \ - "vmeta.common.vsi=14,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.add_vlan_and_send_to_port(1,24)" -p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_host_to_ovs_table \ - "vmeta.common.vsi=14,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(24)" -p4rt-ctl add-entry br0 linux_networking_control.vlan_push_mod_table \ - "vmeta.common.mod_blob_ptr=1,action=linux_networking_control.vlan_push(1,0,1)" +Once these tables are configured refer to packet flow as mentioned below. -# Rules for control packets coming from overlay VF (VSI-15). -# IPU will add a VLAN tag 2 and send to HOST1 (VSI-8). +#### For Tx -p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_host_to_ovs_and_ovs_to_wire_table \ - "vmeta.common.vsi=15,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.add_vlan_and_send_to_port(2,24)" -p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_host_to_ovs_table \ - "vmeta.common.vsi=15,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(24)" -p4rt-ctl add-entry br0 linux_networking_control.vlan_push_mod_table \ - "vmeta.common.mod_blob_ptr=2,action=linux_networking_control.vlan_push(1,0,2)" +##### Egress traffic without VxLAN encapsulation -# Rules for control packets coming from HOST1 (VSI-8). -# IPU will remove the VLAN tag 1 and send to overlay VF (VSI-14). +Packets coming from overlay network: -p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_ovs_to_host_table \ - "vmeta.common.vsi=8,hdrs.dot1q_tag[vmeta.common.depth].hdr.vid=1,action=linux_networking_control.remove_vlan_and_send_to_port(1,30)" -p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_ovs_to_host_table \ - "vmeta.misc_internal.vm_to_vm_or_port_to_port[27:17]=14,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(30)" -p4rt-ctl add-entry br0 linux_networking_control.vlan_pop_mod_table \ - "vmeta.common.mod_blob_ptr=1,action=linux_networking_control.vlan_pop" +- Determine the source port of the packet based on which overlay VSI the packet has landed on. +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, check if SMAC of the packet is learnt. +- Check if DMAC packet is learnt against the bridge derived above. If entry matches, forward the packet to VF corresponding to the physical port. +- Sample OvS config: -# Rules for control packets coming from HOST1 (VSI-8). -# IPU will remove the VLAN tag 2 and send to overlay VF (VSI-15). + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ``` -p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_ovs_to_host_table \ - "vmeta.common.vsi=8,hdrs.dot1q_tag[vmeta.common.depth].hdr.vid=2,action=linux_networking_control.remove_vlan_and_send_to_port(2,31)" -p4rt-ctl add-entry br0 linux_networking_control.handle_rx_loopback_from_ovs_to_host_table \ - "vmeta.misc_internal.vm_to_vm_or_port_to_port[27:17]=15,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(31)" -p4rt-ctl add-entry br0 linux_networking_control.vlan_pop_mod_table \ - "vmeta.common.mod_blob_ptr=2,action=linux_networking_control.vlan_pop" -``` +##### Egress traffic with VxLAN encapsulation -### Configure rules for underlay control packets +Packets coming from overlay network: -Configure rules to send underlay control packets from IDPF netdev to physical port. +- Determine the source port of the packet based on which overlay VSI the packet has landed on. +- Check if the DMAC of the packet is reachable via the VxLAN tunnel and set the remote_ip of the tunnel. +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, check if SMAC of the packet is learnt. +- Check if DMAC packet is learnt against the bridge derived above. If yes, populated Src IP, Dest IP, VNI, SRC port and Dest port of outer packet. +- Based on the above derived remote_ip, retrieve what is the nexthop from ipv4_table. +- Derive from which physical port this nexthop is learnt and add the nexthop MAC address as DMAC and underlay port MAC as SMAC of the packet. +- Sample OvS config: -Below configuration assumes + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ovs-vsctl add-br br-tep-termination ## this bridge has IP to reach remote TEP + ovs-vsctl add-port br-tep-termination + ``` -- Underlay IDPF netdev has a VSI value 10 -- First physical port will have a port ID of 0 +#### For Rx -```bash -# Configuration for control packets between physical port 0 to underlay IDPF netdev VSI-10 -p4rt-ctl add-entry br0 linux_networking_control.handle_rx_from_wire_to_ovs_table \ - "vmeta.common.port_id=0,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(26)" +##### Ingress traffic without VxLAN encapsulation -# Configuration for control packets between underlay IDPF netdev VSI-10 to physical port 0 -p4rt-ctl add-entry br0 linux_networking_control.handle_tx_from_host_to_ovs_and_ovs_to_wire_table \ - "vmeta.common.vsi=10,user_meta.cmeta.bit32_zeros=0,action=linux_networking_control.set_dest(0)" -``` +If the packet coming from a remote machine to the physical port is not VxLAN encapsulated packet: -### Underlay configuration +- Determine the source port of the packet based on which physical port the packet has landed on. +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, check if the inner SMAC of the packet is learnt. +- Check if the inner DMAC packet is learnt against the bridge derived above. If entry matches, forward the packet to VF corresponding to the overlay VM. +- Sample OvS config: -Configure underlay IP addresses, and add static routes. + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ``` -Below configuration assumes +##### Ingress traffic with VxLAN encapsulation -- Underlay IDPF netdev has a VSI value 10 +If the packet coming from a remote machine to the physical port are VxLAN encapsulated packet: -```bash -p4rt-ctl add-entry br0 linux_networking_control.ecmp_lpm_root_lut \ - "user_meta.cmeta.bit32_zeros=4/255.255.255.255,priority=2,action=linux_networking_control.ecmp_lpm_root_lut_action(0)" +- Determine the source port of the packet based on which physical port the packet has landed +- Validate if the source port is part of the bridge, else drop the packet. +- If valid bridge configuration is found, check if the inner SMAC of the packet is learnt. +- Check if the inner DMAC packet is learnt against the bridge derived above. If entry matches, decap the outer packet and forward the inner packet to the overlay VF where DMAC is learnt. +- Sample OvS config: -nmcli device set managed no -ifconfig 40.1.1.1/24 up -ip route show -ip route change 40.1.1.0/24 via 40.1.1.2 dev -``` + ```bash + ovs-vsctl add-br br-int + ovs-vsctl add-port br-int + ovs-vsctl add-port br-int + ovs-vsctl add-br br-tep-termination ## this bridge has IP to reach remote TEP + ovs-vsctl add-port br-tep-termination + ``` -### Test the ping scenarios +## Summary -- Ping between VM's on the same host -- Underlay ping -- Overlay ping: Ping between VM's on different hosts +- Verification of source port and associated L2 Bridge: The P4 Control Plane (P4 CP) must ensure the validation of the source port and its corresponding L2 bridge before initiating any further regulation of datapath packet classification. +- Exception packet handling for all protocols: The P4 Control Plane (P4 CP) shall incorporate exception packet handling logic, not limited to ARP but applicable to the first packet of any protocol. +- Offloading of networking functions: The P4 Control Plane (P4 CP) software shall provide support for the offloading of various networking functions as specified in the Linux Networking use case. These networking functions include Layer 2 (L2) and Layer 3 (L3) forwarding, Equal-Cost Multi-Path (ECMP) routing, Link Aggregation Group (LAG), as well as Virtual Extensible LAN (VXLAN) encapsulation and decapsulation. These functions shall support both single and multiple Open vSwitch (OvS) bridges. ## Limitations -Current Linux Networking support for the networking recipe has following limitations: - -- All VLAN interfaces created on top of IDPF netdev, should always be in lowercase format "vlan+vlan_id" -Ex: vlan1, vlan2, vlan3 ... vlan4094. -- Set the pipeline before adding br-int port, vxlan0 port, and adding vlan ports to br-int bridge. -- VxLAN destination port should always be standard port. i.e., 4789. (limitation by p4 parser) -- We do not support any ofproto rules that would prevent FDB learning on OvS. -- VLAN Tagged packets are not supported. -- For VxLAN tunneled packets only IPv4-in-IPv4 is supported. +Current Linux Networking support for the networking recipe has the following limitations: + +- VLAN configuration on OvS is supported only for NATIVE-TAG and NATIVE-UNTAG modes. +- Physical port's port representor should be added as the first port in tunnel TEP bridge (br-tep-termination). +- Only OvS bridges are supported. +- Configure p4rt-ctl runtime rules before OvS configuration. +- Double vlan tag is NOT supported. +- Add all ACC PR's to VSI group 1. +- On ACC, firewall needs to be disabled. Otherwise, this service will block encapsulated packets. + - systemctl stop firewalld +- See LNW-V2 README_P4_CP_NWS, which comes with the P4 program for more information about limitations in router_interface_id action in nexthop_table(Defect filed). + - Manually modify context.json to remove NOP hardware action for in context.json from "set_nexthop " action in "nexthop_table". Open defect is present in p4-sde to fix this issue. Content to be removed under hardware action in context.json is +```text +{ + "prec": 0, + "action_code": "NOP", + "index": 0, + "value": 0, + "mask": 0 +}, +``` diff --git a/docs/apps/lnw/es2k/es2k-lnw-overlay-vms.md b/docs/apps/lnw/es2k/es2k-lnw-overlay-vms.md new file mode 100644 index 00000000..2c9bd2ca --- /dev/null +++ b/docs/apps/lnw/es2k/es2k-lnw-overlay-vms.md @@ -0,0 +1,353 @@ +# Linux Networking with Overlay VMs + +This document explains how to run the Linux networking scenario on ES2K with 8 overlay VMs. + +## Topology + +![Linux Networking Topology](es2k-lnw-topology.png) + +See [Linux Networking for ES2K](es2k-linux-networking.md) +for more details on this feature. + +Prerequisites: + +- Download `hw-p4-programs` TAR file specific to the build and extract it to get `fxp-net_linux-networking-v2` p4 artifacts. Go through `Limitations` specified in `README` and bringup the setup accordingly. +- Follow steps mentioned in [Deploying P4 Programs for E2100](/guides/es2k/deploying-p4-programs) for bringing up IPU with a custom P4 package. +Modify `load_custom_pkg.sh` with following parameters for linux_networking package: +```text + sed -i 's/sem_num_pages = 1;/sem_num_pages = 25;/g' $CP_INIT_CFG + sed -i 's/lem_num_pages = 1;/lem_num_pages = 10;/g' $CP_INIT_CFG + sed -i 's/acc_apf = 4;/acc_apf = 16;/g' $CP_INIT_CFG + +``` +- Download `IPU_Documentation` TAR file specific to the build and refer to `Getting Started Guide` on how to install compatible `IDPF driver` on host. Once an IDPF driver is installed, bring up SRIOV VF by modifying the `sriov_numvfs` file present under one of the IDPF network devices. Example as below + + ```bash + echo 16 > /sys/class/net/ens802f0/device/sriov_numvfs + ``` + +Notes about topology: + +- VMs are spawned on top of each VF. Each VF will have a port representor in ACC. P4 runtime rules are configured to map VFs and their corresponding port representors. +- Each physical port will have a port representor in ACC. P4 runtime rules are configured to map VFs and its corresponding port representors. +- Each physical port will have a corresponding APF netdev on HOST. Create port representors in ACC for each HOST APF netdev. These APF netdev on HOST will receive unknown traffic for applications to act on. +- All port representors should be part of an OvS bridge. Based on topology, these OvS bridges will just perform bridging or TEP termination bridges which are used to enable underlay connectivity for VxLAN traffic. +- OvS bridges, VxLAN ports are created using ovs-vsctl command provided by the networking recipe and all the port representors are attached to OvS bridge using ovs-vsctl command. +- This config has: + - 8 Overlay VFs + - 8 Port representors in ACC for the above 8 Overlay VFs + - 2 physical ports + - 2 Port representors in ACC for the above 2 physical ports + - 2 APF netdev on HOST + - 2 Port representors in ACC for the above 2 HOST APF netdevs + +System under test will have above topology running the networking recipe. Link Partner can have the networking recipe or legacy OvS or kernel VxLAN. Refer to the limitation section in [Linux Networking for E2100](es2k-linux-networking.md) before setting up the topology. + +## Creating the topology + +Follow steps mentioned in [Running Infrap4d on Intel E2100](/guides/es2k/running-infrap4d.md) for starting `infrap4d` process and creating protobuf binary for `fxp-net_linux-networking-v2` p4 program. + +### Port Mapping + +These VSI values can be checked with `/usr/bin/cli_client -q -c` command on IMC. This command provides VSI ID, Vport ID, and corresponding MAC addresses for all + +- IDPF netdevs on ACC +- VFs on HOST +- IDPF netdevs on HOST (if IDPF driver loaded by you on HOST) +- Netdevs on IMC + +| Overlay VFs | Overlay VFs VSI ID | ACC port representor | ACC port representor VSI ID | +| ------------| ------------------ | -------------------- | --------------------------- | +| ens802f0v0 | (0x1b) 27 | enp0s1f0d1 | (0x09) 9 | +| ens802f0v1 | (0x1c) 28 | enp0s1f0d2 | (0x0a) 10 | +| ens802f0v4 | (0x1d) 29 | enp0s1f0d3 | (0x0b) 11 | +| ens802f0v3 | (0x1e) 30 | enp0s1f0d4 | (0x0c) 12 | +| ens802f0v2 | (0x1f) 31 | enp0s1f0d5 | (0x0d) 13 | +| ens802f0v11 | (0x20) 32 | enp0s1f0d6 | (0x0e) 14 | +| ens802f0v10 | (0x21) 33 | enp0s1f0d7 | (0x0f) 15 | +| ens802f0v9 | (0x22) 34 | enp0s1f0d8 | (0x10) 16 | + +| Physical port | Physical port ID | ACC Port presenter | ACC Port presenter VSI ID | +| ------------- | ----------------- | -------------------- | ------------------------- | +| Phy port 0 | (0x0) 0 | enp0s1f0d9 | (0x11) 17 | +| Phy port 1 | (0x1) 1 | enp0s1f0d11 | (0x13) 19 | + +| APF netdev | APF netdev VSI ID | ACC Port presenter | ACC Port presenter VSI ID | +| ------------- | ----------------- | -------------------- | ------------------------- | +| ens802f0d1 | (0x18) 24 | enp0s1f0d10 | (0x12) 18 | +| ens802f0d2 | (0x19) 25 | enp0s1f0d12 | (0x14) 20 | + +(NOTE: Above port names and its VSI ID's may different from setup to setup, configure accordingly) + +### Set the forwarding pipeline + +Once the application is started, set the forwarding pipeline config using +P4Runtime Client `p4rt-ctl` set-pipe command + +```bash +$P4CP_INSTALL/bin/p4rt-ctl set-pipe br0 $OUTPUT_DIR/fxp-net_linux-networking-v2.pb.bin \ + $OUTPUT_DIR/p4info.txt +``` + +Note: Assuming `fxp-net_linux-networking-v2.pb.bin` and `p4info.txt` +along with other P4 artifacts are created as per the steps mentioned in the previous section. + +### Configure VSI Group and add a netdev + +Add all ACC port representors to VSI group 1. VSI group 1 is dedicated for this configuration, +execute below devmem commands on IMC. + +```bash +# SEM_DIRECT_MAP_PGEN_CTRL: LSB 11-bit is for vsi which need to map into vsig +devmem 0x20292002a0 64 0x8000050000000009 + +# SEM_DIRECT_MAP_PGEN_DATA_VSI_GROUP : This will set vsi +# (set in SEM_DIRECT_MAP_PGEN_CTRL register LSB) into VSIG-1. +devmem 0x2029200388 64 0x1 + +# SEM_DIRECT_MAP_PGEN_CTRL: LSB 11-bit is for vsi which need to map into vsig +devmem 0x20292002a0 64 0xA000050000000009 +``` + +Note: Here VSI 9 has been used as one of the ACC port representors and added to VSI group 1. For this use case add all 16 IDPF interfaces created on ACC. Modify this VSI based on your configuration. + +### Start OvS as a separate process + +Enhanced OvS is used as a control plane for source MAC learning of overlay VM's. This OvS binary is available as part of ACC build and should be started as a separate process. + +```bash +export RUN_OVS=/opt/p4/p4-cp-nws + +rm -rf $RUN_OVS/etc/openvswitch +rm -rf $RUN_OVS/var/run/openvswitch +mkdir -p $RUN_OVS/etc/openvswitch/ +mkdir -p $RUN_OVS/var/run/openvswitch + + +ovsdb-tool create $RUN_OVS/etc/openvswitch/conf.db \ + $RUN_OVS/share/openvswitch/vswitch.ovsschema + +ovsdb-server \ + --remote=punix:$RUN_OVS/var/run/openvswitch/db.sock \ + --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ + --pidfile --detach + +ovs-vsctl --no-wait init + +mkdir -p /tmp/logs +ovs-vswitchd --pidfile --detach --mlockall \ + --log-file=/tmp/logs/ovs-vswitchd.log + +ovs-vsctl set Open_vSwitch . other_config:n-revalidator-threads=1 +ovs-vsctl set Open_vSwitch . other_config:n-handler-threads=1 + +ovs-vsctl show +``` + +### Create Overlay network + +Option 1: Create VFs on HOST and spawn VMs on top of those VFs. +Example: Below config is provided for one VM, and considering each VM is in one VLAN. Extend this to 8 VMs. + +```bash +# VM1 configuration +telnet +ip link add link name .10 type vlan id 10 +ip addr add 101.0.0.1/24 dev .10 +ifconfig up +ifconfig .10 up +``` + +Option 2: If we are unable to spawn VM's on top of the VF's, we can leverage kernel network namespaces. +Move each VF to a network namespace and assign IP addresses. +Example: Below config is provided for one VM, and considering each namespace is in one VLAN. Extend this to 8 namespaces. + +```bash +ip netns add VM0 +ip link set netns VM0 +ip netns exec VM0 ip link add link name .10 type vlan id 10 +ip netns exec VM0 ip addr add 101.0.0.1/24 dev .10 +ip netns exec VM0 ifconfig up +ip netns exec VM0 ifconfig .10 up +``` + +### Configure rules for mapping between Overlay VF and ACC port representor + +Configure rules to send overlay packets from a VM to its respective port representors. + +Refer above port mapping for overlay VF to ACC port representor mapping. Here sample commands are shown for a single overlay network, configure similar mapping for remaining VFs. + +Example: + +- Overlay VF1 has a VSI value 27 +- Corresponding port representor VSI value 9 +- If a VSI is used as an action, add an offset of 16 to the VSI value + +```bash +# Create a source port for an overlay VF (VSI-27). Source port action can be any value. +# For simplicity add 16 to VSI ID. + p4rt-ctl add-entry br0 linux_networking_control.tx_source_port_v4 \ + "vmeta.common.vsi=27,zero_padding=0,action=linux_networking_control.set_source_port(43)" + +# Create a mapping between overlay VF (VSI-27/source port-43) and ACC port representor (VSI-9) + p4rt-ctl add-entry br0 linux_networking_control.source_port_to_pr_map \ + "user_meta.cmeta.source_port=43,zero_padding=0,action=linux_networking_control.fwd_to_vsi(25)" + + p4rt-ctl add-entry br0 linux_networking_control.tx_acc_vsi \ + "vmeta.common.vsi=9,zero_padding=0,action=linux_networking_control.l2_fwd_and_bypass_bridge(43)" + +# Create a mapping for traffic to flow between VSIs (VSI-27/source port-43) and (VSI-9) + p4rt-ctl add-entry br0 linux_networking_control.vsi_to_vsi_loopback \ + "vmeta.common.vsi=9,target_vsi=27,action=linux_networking_control.fwd_to_vsi(43)" + + p4rt-ctl add-entry br0 linux_networking_control.vsi_to_vsi_loopback \ + "vmeta.common.vsi=27,target_vsi=9,action=linux_networking_control.fwd_to_vsi(25)" + +``` + +### Configure rules for mapping between Physical port and ACC port representor + +Configure rules to send ingress packets from a physical port to its respective port representors. + +Refer above port mapping for physical port to ACC port representor mapping. Here sample commands are shown for a single physical port, configure similar mapping for remaining physical ports. + +Example: + +- Physical port 0 port id is 0 +- Corresponding port representor VSI value 17 +- If a VSI is used as an action, add an offset of 16 to the VSI value + +```bash +# Create a source port for a physical port (Phy port-0). Source port action can be any value. +# For simplicity consider the same value as phy port id. + p4rt-ctl add-entry br0 linux_networking_control.rx_source_port \ + "vmeta.common.port_id=0,zero_padding=0,action=linux_networking_control.set_source_port(0)" + +# Create a mapping between physical port (Phy port 0/src port 0) and ACC port representor (VSI-17) + p4rt-ctl add-entry br0 linux_networking_control.rx_phy_port_to_pr_map \ + "vmeta.common.port_id=0,zero_padding=0,action=linux_networking_control.fwd_to_vsi(33)" + + p4rt-ctl add-entry br0 linux_networking_control.source_port_to_pr_map \ + "user_meta.cmeta.source_port=0,zero_padding=0,action=linux_networking_control.fwd_to_vsi(33)" + + p4rt-ctl add-entry br0 linux_networking_control.tx_acc_vsi \ + "vmeta.common.vsi=17,zero_padding=0,action=linux_networking_control.l2_fwd_and_bypass_bridge(0)" +``` + +### Configure rules for mapping between APF netdev on HOST and ACC port representor + +Configure rules to send APF netdev on HOST to its respective port representors. + +Refer above port mapping for APF netdev on HOST to ACC port representor mapping. Here sample commands are shown for APF netdev on HOST, configure similar mapping for remaining APF netdevs on HOST. + +Example: + +- APF netdev 1 on HOST has a VSI value 24 +- Corresponding port representor VSI value 18 +- If a VSI is used as an action, add an offset of 16 to the VSI value + +```bash +# Create a source port for an overlay VF (VSI-24). Source port action can be any value. +# For simplicity add 16 to VSI ID. + p4rt-ctl add-entry br0 linux_networking_control.tx_source_port_v4 \ + "vmeta.common.vsi=24,zero_padding=0,action=linux_networking_control.set_source_port(40)" + + +# Create a mapping between overlay VF (VSI-24/source port-40) and ACC port representor (VSI-18) + p4rt-ctl add-entry br0 linux_networking_control.source_port_to_pr_map \ + "user_meta.cmeta.source_port=40,zero_padding=0,action=linux_networking_control.fwd_to_vsi(34)" + + p4rt-ctl add-entry br0 linux_networking_control.tx_acc_vsi \ + "vmeta.common.vsi=17,zero_padding=0,action=linux_networking_control.l2_fwd_and_bypass_bridge(0)" + +# Create a mapping for traffic to flow between VSIs (VSI-24/source port-40) and (VSI-18) + p4rt-ctl add-entry br0 linux_networking_control.vsi_to_vsi_loopback \ + "vmeta.common.vsi=18,target_vsi=24,action=linux_networking_control.fwd_to_vsi(40)" + + p4rt-ctl add-entry br0 linux_networking_control.vsi_to_vsi_loopback \ + "vmeta.common.vsi=24,target_vsi=18,action=linux_networking_control.fwd_to_vsi(34)" +``` + +### Configure supporting p4 runtime tables + +For TCAM entry configure LPM LUT table + +```bash + p4rt-ctl add-entry br0 linux_networking_control.ipv4_lpm_root_lut \ + "user_meta.cmeta.bit32_zeros=4/255.255.255.255,priority=65535,action=linux_networking_control.ipv4_lpm_root_lut_action(0)" +``` + +Create a dummy LAG bypass table for all 8 hash indexes + +```bash + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=0,action=linux_networking_control.bypass" + + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=1,action=linux_networking_control.bypass" + + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=2,action=linux_networking_control.bypass" + + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=3,action=linux_networking_control.bypass" + + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=4,action=linux_networking_control.bypass" + + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=5,action=linux_networking_control.bypass" + + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=6,action=linux_networking_control.bypass" + + p4rt-ctl add-entry br0 linux_networking_control.tx_lag_table \ + "user_meta.cmeta.lag_group_id=0,hash=7,action=linux_networking_control.bypass" +``` + +### Create integration bridge and add ports to the bridge + +Create OvS bridge, VxLAN tunnel and assign overlay VFs port representor to individual bridges. +Reference provided for single overlay network, repeat similar steps for other VFs. + +Each bridge has: + +- One overlay PR which is Native-tagged to a specific VLAN +- One VxLAN port which is Native-untagged to the VLAN and with different remote TEP and VNI + +```bash +ovs-vsctl add-br br-1 +ovs-vsctl add-port br-1 enp0s1f0d1 tag=10 vlan_mode=native-tagged +ovs-vsctl add-port br-1 vxlan1 tag=10 vlan_mode=native-untagged -- set interface vxlan1 type=vxlan \ + options:local_ip=10.1.1.1 options:remote_ip=10.1.1.2 options:key=10 options:dst_port=4789 +``` + +Note: Here we are creating a VxLAN tunnel with VNI 0, you can create any VNI for tunneling. + +### Underlay configuration + +Create TEP termination bridge, add physical port's port representor and APF netdev port representor. +Reference provided for underlay network, repeat similar steps for multiple underlay networks. + +```bash +ovs-vsctl add-br br-tun-1 +ovs-vsctl add-port br-tun-1 enp0s1f0d9 +ovs-vsctl add-port br-tun-1 enp0s1f0d10 +``` + +Configure underlay IP address on the TEP termination port, route to reach remote IP is on termination bridge, and add change routes to reach remote IP. + +```bash +# Create a dummy port and add TEP local IP +ip link add dev TEP10 type dummy +ifconfig TEP10 10.1.1.1/24 up + +# On termiantion bridge, configure an IP to reach remote TEP, and modify route to include nexthop details. +ifconfig br-tun-1 1.1.1.1/24 up +ip route change 10.1.1.0/24 via 1.1.1.2 dev br-tun-1 +``` + +### Test the ping scenarios + +- Underlay ping +- Overlay ping: Ping between VMs on different hosts diff --git a/docs/apps/lnw/es2k/es2k-lnw-topology.png b/docs/apps/lnw/es2k/es2k-lnw-topology.png index 4a952241..5e16a043 100644 Binary files a/docs/apps/lnw/es2k/es2k-lnw-topology.png and b/docs/apps/lnw/es2k/es2k-lnw-topology.png differ diff --git a/docs/apps/lnw/lnw-index.rst b/docs/apps/lnw/lnw-index.rst index 993c9117..68392f8a 100644 --- a/docs/apps/lnw/lnw-index.rst +++ b/docs/apps/lnw/lnw-index.rst @@ -21,7 +21,9 @@ ES2K :maxdepth: 1 es2k/es2k-linux-networking + es2k/es2k-lnw-overlay-vms es2k/es2k-linux-networking-ipv6 es2k/es2k-linux-networking-ecmp es2k/es2k-linux-networking-frr - \ No newline at end of file + es2k/es2k-linux-networking-lag + diff --git a/docs/apps/packet-io.md b/docs/apps/packet-io.md new file mode 100644 index 00000000..9528436b --- /dev/null +++ b/docs/apps/packet-io.md @@ -0,0 +1,111 @@ +# Packet I/O + +The Packet I/O feature facilitates the exchange of packets between control plane +applications and P4 dataplanes. +This functionality enables control plane applications to receive packets +asynchronously from the dataplane, while also allowing the injection +of packets into the dataplane. + +The Packet I/O feature is currently supported on the Intel® IPU E2100 target. + +## Feature overview + +Packet I/O consists of two essential components: Packet-In and Packet-Out. + +- **Packet-In**: Refers to a data plane packet sent by the P4Runtime server + to the control plane for further analysis. This is specified as `packetIn` + message response in the [p4runtime specification](https://github.com/ipdk-io/p4runtime-dev/blob/mirroring/proto/p4/v1/p4runtime.proto). +- **Packet-Out**: Defined as a data packet originated by the control plane + and injected into the data plane through the P4Runtime server. + This is specified as `packetOut` in p4runtime specification. + +During the set pipeline sequence, the Packet I/O configuration is extracted +from the pipeline configuration. This configuration is then utilized to +register Rx and Tx callbacks with the device driver. When a packet is +received, the device driver invokes the RX callback, and when a packet is +transmitted, the Tx callback is triggered. + +### Rx Path + +The P4 device driver invokes the registered Rx callback upon receiving a packet, +passing the packet details to the Stratum layer of `infrap4d`. The Stratum layer +parses the received packet and translates it into a PacketIn message as defined +in p4runtime.proto. The P4Runtime server sends the PacketIn message to the +connected client. + +### Tx Path + +A P4runtime client/controller can send packets to the PacketIO port as a +PacketOut message defined in p4runtime.proto. The P4CP Stratum layer translates +the PacketOut message to TDI structures and sends them to the driver. + +## Enabling Packet I/O + +To enable the Packet I/O feature, add the `pktio-args` configuration to the following files: + +- The configuration file used by the `infrap4d` process. +- The configuration file used by `tdi_pipeline_builder`. + +The Packet I/O configuration is per device and should be added under the +`p4_devices` section. + +### Packet I/O configuration + +```json + "pktio-args": { + "ports" // list of ports to receive and transmit packetIO packets + "nb_rxqs" // number of rx queues per port + "nb_txqs" // number of tx queues per port + }, +``` + +### Example + +```json + "p4_devices": [ + { + "device-id": 0, + "fixed_functions" : [], + "eal-args": "--lcores=1-2 -a af:00.6,vport=[0-1] -- -i --rxq=1 --txq=1 --hairpinq=1 --hairpin-mode=0x0", + "pktio-args": { + "ports": [0,1], + "nb_rxqs" : 4, + "nb_txqs" : 4 + }, +``` + +Follow the sequence of steps listed below to enable Packet I/O functionality. + +### Configure and run infrap4d + +The `infrap4d` process provides the gRPC server-side support for P4Runtime +packetIn and packetOut messages. + +To start `infrap4d` process with Packet I/O, the +/usr/share/stratum/es2k/es2k_skip_p4.conf file must include Packet IO +configuration. +Instructions to run infrap4d can be found at [running infrap4d](/guides/es2k/running-infrap4d.md) + +Ensure you update this configuration before starting `infrap4d`. + +### Configure and set the pipeline + +The Packet IO configuration mentioned above should also be present in the +configuration file provided with the `p4c_conf_file` option for building +the pipeline. +Instructions to build and set pipeline can be found at [set pipeline](/guides/setup/es2k-setup-guide.md) + +## Reference client + +The `p4rt-ctl` client can be used to exercise the Packet I/O feature. +See "Start Packet I/O" in the [p4rt-ctl guide](/clients/p4rt-ctl.rst) for instructions. + +In Packet I/O mode, the following steps take place: + +- The p4rt-ctl client initializes a `pktioTap0` port designed for testing purposes. + This port facilitates the sending and receiving of packets. +- The packets sent to pktioTap0 port are forwarded to P4Runtime server as + `PacketOut` messages. +- The p4rt-ctl client establishes a connection with the P4Runtime server and awaits + incoming RX packets from the server. Subsequently, the received packets are + forwarded to the pktioTap0 port. diff --git a/docs/clients/p4rt-ctl.rst b/docs/clients/p4rt-ctl.rst index cd7e1bfe..9111cc6e 100644 --- a/docs/clients/p4rt-ctl.rst +++ b/docs/clients/p4rt-ctl.rst @@ -549,6 +549,23 @@ Examples: p4rt-ctl get-packet-mod-meter br0 my_control.meter1 "meter_id=2244878476,meter_index=10" +Start Packet I/O +~~~~~~~~~~~~~~~~ + +.. code-block:: bash + + p4rt-ctl start-pktio SWITCH + +Arguments: + +* ``SWITCH``: Bridge name. Maps internally to device name. + +Examples: + +.. code-block:: bash + + p4rt-ctl start-pktio br0 + Known Issues ------------ diff --git a/docs/guides/es2k/building-acc-p4cp.md b/docs/guides/es2k/building-acc-p4cp.md index 1cf41b98..c29f405a 100644 --- a/docs/guides/es2k/building-acc-p4cp.md +++ b/docs/guides/es2k/building-acc-p4cp.md @@ -33,17 +33,17 @@ If you have not already done so, you will need to get a copy of the IPDK networking-recipe repository and its submodules: ```bash -git clone --recursive https://github.com/ipdk-io/networking-recipe.git ipdk.recipe +git clone --recursive https://github.com/ipdk-io/networking-recipe.git p4cp.recipe ``` -You may substitute your own local directory name for `ipdk.recipe`. +You may substitute your own local directory name for `p4cp.recipe`. ## Define the Environment First, change to the source directory: ```bash -cd ipdk.recipe +cd p4cp.recipe ``` Source the file that defines the diff --git a/docs/guides/es2k/defining-acc-environment.md b/docs/guides/es2k/defining-acc-environment.md index 859761d3..fe600d85 100644 --- a/docs/guides/es2k/defining-acc-environment.md +++ b/docs/guides/es2k/defining-acc-environment.md @@ -43,7 +43,7 @@ In the listing above, you will need to provide values for these variables: - `ACC_SDK` - install path of the ACC-RL SDK (for example, `$HOME/p4cp-dev/acc_sdk`) - `P4CPBASE` - path to the local networking-recipe directory (for example, - `$HOME/p4cp-dev/ipdk.recipe`) + `$HOME/p4cp-dev/p4cp.recipe`) From these paths, the setup script derives: diff --git a/docs/guides/es2k/deploying-p4-programs.md b/docs/guides/es2k/deploying-p4-programs.md index 373b88d0..d4bf97d7 100644 --- a/docs/guides/es2k/deploying-p4-programs.md +++ b/docs/guides/es2k/deploying-p4-programs.md @@ -14,47 +14,47 @@ to generate the P4 artifacts required for deployment. Data Path Control Plane (DPCP) starts with a default P4 package. To load a custom P4 package follow below steps: -### 2.1 Interrupt default startup routine +### 2.1 Copy the custom P4 package -Reboot IMC and type ``N`` when the following message is shown on IMC console:: +Copy the custom P4 package (p4_custom.pkg) in `/work/scripts` directory to IMC. -```text -start ipumgmtd and auxiliary script [Y/N] \ -(default start both automatically after 10 seconds)? -``` - -### 2.2 Copy the custom P4 package +### 2.2 Modify the script responsible for loading custom package -Copy the custom P4 package (.pkg) in `/etc/dpcp/package` directory and -overwrite the `default_pkg.pkg`. +Replace the `p4_custom.pkg` with custom package name in `load_custom_pkg.sh` script. -For example, replace `default_pkg.pkg` with `simple_l3_l4_pna.pkg` +Any modifications intended in node policy `cp_init.cfg` should be provided as part of +the same script. ```bash -root@mev-imc:/etc/dpcp/package# ls -lrt /etc/dpcp/package/ -total 2364 --rw-r--r-- 1 root root 963032 Jan 1 04:56 simple_l3_l4_pna.pkg --rw-r--r-- 1 root root 1450456 Jun 8 2023 e2100-default-1.0.3.0.pkg -drwxr-xr-x 2 root root 0 Jun 8 2023 runtime_files -drwxr-xr-x 3 root root 0 Jun 8 2023 ref_pkg -lrwxrwxrwx 1 root root 25 Jun 8 2023 default_pkg.pkg -> e2100-default-1.0.3.0.pkg -root@mev-imc:/etc/dpcp/package# cp simple_l3_l4_pna.pkg default_pkg.pkg +[root@ipu-imc /]# cd /work/scripts +[root@ipu-imc scripts]# cat load_custom_pkg.sh +#!/bin/sh +CP_INIT_CFG=/etc/dpcp/cfg/cp_init.cfg +echo "Checking for custom package..." +if [ -e p4_custom.pkg ]; then + echo "Custom package p4_custom.pkg found. Overriding default package" + cp p4_custom.pkg /etc/dpcp/package/ + rm -rf /etc/dpcp/package/default_pkg.pkg + ln -s /etc/dpcp/package/ p4_custom.pkg /etc/dpcp/package/default_pkg.pkg + sed -i 's/sem_num_pages = 1;/sem_num_pages = 25;/g' $CP_INIT_CFG +else + echo "No custom package found. Continuing with default package" +fi ``` If Communication Channel support is required, [enable the communication channel](enabling-comm-channel.md) before proceeding to the next step. -### 2.3 Start the IMC - -Run the IMC start-up script. +### 2.3 Reboot the IMC ```bash -root@mev-imc:~# /etc/init.d/run_default_init_app +root@mev-imc:~# reboot ``` +Once the IMC reboots successfully, IPU is loaded with the custom P4 package. -By default, `cpf_host` parameter in `/etc/dpcp/cfg/cp_init.cfg` is set to 4 which -enables ACC. If the start-up script is executed successfully, ACC comes up with a +By default, `cpf_host` parameter in node_policy is set to 4 which +enables ACC. If the IMC reboots successfully, ACC comes up with a statically assigned IP address `192.168.0.2` to the eth0 network interface. You can access ACC from IMC over an SSH session using this IP address. diff --git a/docs/guides/es2k/enabling-comm-channel.md b/docs/guides/es2k/enabling-comm-channel.md index d1220aa1..18c4d003 100644 --- a/docs/guides/es2k/enabling-comm-channel.md +++ b/docs/guides/es2k/enabling-comm-channel.md @@ -7,52 +7,40 @@ running on the Host to communicate with infrap4d running on the ACC. Ports used for communication channels are defined by the node policy on IMC. -## 1. Interrupt default start-up routine +## 1 Modify the custom package config script on IMC -Reboot IMC and type ``N`` when the following message is shown on IMC console:: +Modify the `load_custom_pkg.sh` script to specify comm_vports. -```text -start ipumgmtd and auxiliary script [Y/N] \ -(default start both automatically after 10 seconds)? -``` - -## 2. Specify communication channel ports - -The config file uses the function numbers that are defined as below: - -| Function number | Definition | -|------------------------|-------------------| -| 0 | Xeon Host | -| 4 | ACC | -| 5 | IMC | - -Format used to indicate communication channels: -`(([function number, vport_index],[pf_num, vport_index]),...)` - -Modify `/etc/dpcp/cfg/cp_init.cfg` to change the value of `comm_vports`. - -```text -/* IMC_LAN_APF_VPORT_0 ([5,0]) <--> ACC_APF_VPORT_0 ([4,0]) */ -/* HOST0_LAN_APF_VPORT_3 ([0, 3]) <--> ACC_LAN_APF_VPORT_3 [(4,2)]*/ -comm_vports = (([5,0],[4,0]),([0,3],[4,2])); +```bash +[root@ipu-imc /]# cd /work/scripts +[root@ipu-imc scripts]# cat load_custom_pkg.sh +#!/bin/sh +CP_INIT_CFG=/etc/dpcp/cfg/cp_init.cfg +echo "Checking for custom package..." +if [ -e p4_custom.pkg ]; then + echo "Custom package p4_custom.pkg found. Overriding default package" + cp p4_custom.pkg /etc/dpcp/package/ + rm -rf /etc/dpcp/package/default_pkg.pkg + ln -s /etc/dpcp/package/ p4_custom.pkg /etc/dpcp/package/default_pkg.pkg + sed -i 's/sem_num_pages = 1;/sem_num_pages = 25;/g' $CP_INIT_CFG + sed -i "s/comm_vports = ((\[5,0\],\[4,0\]))\;/comm_vports = ((\[5,0\],\[4,0\]),(\[0,3\],\[4,2\]))\;/g" $CP_INIT_CFG +else + echo "No custom package found. Continuing with default package" + sed -i "s/comm_vports = ((\[5,0\],\[4,0\]))\;/comm_vports = ((\[5,0\],\[4,0\]),(\[0,3\],\[4,2\]))\;/g" $CP_INIT_CFG + +fi ``` - This will enable communication between IMC-ACC and Host-ACC. -Note: Changes made to `cp_init.cfg` are not persistent across IMC reboots. - -## 3. Start the IMC - -Run the IMC start-up script. +## 2. Reboot the IMC ```bash -root@mev-imc:~# /etc/init.d/run_default_init_app +root@mev-imc:~# reboot ``` -By default, `cpf_host` parameter in `/etc/dpcp/cfg/cp_init.cfg` is set to 4 which -enables ACC. If the start-up script is executed successfully, ACC comes up with a -statically assigned IP address `192.168.0.2` to the eth0 network interface. -You can access ACC from IMC over an SSH session using this IP address. +If IMC is rebooted successfully, ACC comes up with a statically assigned IP address + `192.168.0.2` to the eth0 network interface. You can access ACC from IMC over an +SSH session using this IP address. ## 3. Load the IDPF driver on Host diff --git a/docs/guides/es2k/running-infrap4d.md b/docs/guides/es2k/running-infrap4d.md index f6b122f2..26818bd0 100644 --- a/docs/guides/es2k/running-infrap4d.md +++ b/docs/guides/es2k/running-infrap4d.md @@ -51,19 +51,23 @@ for step by step guide for generating and installing TLS certificates ## 4. Generate forwarding pipeline binary -### Create tofino.bin - -```bash -export OUTPUT_DIR=/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna -cd $OUTPUT_DIR -touch tofino.bin -``` +Download `hw-p4-programs` TAR file specific to the release build and extract it to get p4 artifacts. +This document explains with `l3-fwd_sem` as a reference P4 program and the P4 artifacts are copied to `/opt/p4/l3-fwd_sem` ### Copy P4 artifacts to ACC -Copy `bfrt.json`, `context.json`, `p4info.txt` to the ACC. See +Copy `bf-rt.json`, `context.json`, `p4info.txt` to the ACC. See [Compiling P4 programs](compiling-p4-programs.md) -for instructions on generating these files. +for instructions on generating these files manually without downloading from +release build. + +### Create ipu.bin + +```bash +export OUTPUT_DIR=/opt/p4/l3-fwd_sem +cd $OUTPUT_DIR +touch ipu.bin +``` ### Prepare configuration file @@ -115,31 +119,31 @@ with the following parameters: - `program-name` - Specify the name of P4 program. For simple_l3_l4_pna example, replace - `P4-PROGRAM-NAME` with `simple_l3_l4_pna` + Specify the name of P4 program. For l3-fwd_sem example, replace + `P4-PROGRAM-NAME` with `l3-fwd_sem` - `p4_pipeline_name` - Specify the name of P4 pipeline. For simple_l3_l4_pna example, replace + Specify the name of P4 pipeline. For l3-fwd_sem example, replace `P4-PIPELINE-NAME` with `main` - `bfrt-config`, `context`, `config` and `path` - Specify the absolute paths for the files. For simple_l3_l4_pna sample program: + Specify the absolute paths for the files. For l3-fwd_sem sample program: Replace `ABSOLUTE-PATH-TO-BFRT-JSON-FILE` with - `/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna/simple_l3_l4_pna.bf-rt.json` + `/opt/p4/l3-fwd_sem/bf-rt.json` Replace `ABSOLUTE-PATH-TO-CONTEXT-JSON-FILE` with - `/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna/simple_l3_l4_pna.context.json` + `/opt/p4/l3-fwd_sem/context.json` Replace `ABSOLUTE-PATH-TO-TOFINO-BIN-FILE` with - `/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna/tofino.bin` + `/opt/p4/l3-fwd_sem/ipu.bin` Replace `ABSOLUTE-PATH-FOR-JSON-FILES` with - `/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna` + `/opt/p4/l3-fwd_sem` -The final es2k_skip_p4.conf for simple_l3_l4_pna sample program will look like: +The final es2k_skip_p4.conf for l3-fwd_sem sample program will look like: ```text { @@ -161,20 +165,20 @@ The final es2k_skip_p4.conf for simple_l3_l4_pna sample program will look like: "eal-args": "--lcores=1-2 -a 00:01.6,vport=[0-1] -- -i --rxq=1 --txq=1 --hairpinq=1 --hairpin-mode=0x0", "p4_programs": [ { - "program-name": "simple_l3_l4_pna", - "bfrt-config": "/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna/simple_l3_l4_pna.bf-rt.json", + "program-name": "l3-fwd_sem", + "bfrt-config": "/opt/p4/l3-fwd_sem/bf-rt.json", "p4_pipelines": [ { "p4_pipeline_name": "main", - "context": "/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna/simple_l3_l4_pna.context.json", - "config": "/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna/tofino.bin", + "context": "/opt/p4/l3-fwd_sem/context.json", + "config": "/opt/p4/l3-fwd_sem/ipu.bin", "pipe_scope": [ 0, 1, 2, 3 ], - "path": "/opt/p4/p4sde/share/mev_reference_p4_files/simple_l3_l4_pna" + "path": "/opt/p4/l3-fwd_sem" } ] } @@ -194,7 +198,7 @@ forwarding pipeline binary. ```bash $P4CP_INSTALL/bin/tdi_pipeline_builder \ --p4c_conf_file=/usr/share/stratum/es2k/es2k_skip_p4.conf \ - --bf_pipeline_config_binary_file=$OUTPUT_DIR/simple_l3_l4_pna.pb.bin + --bf_pipeline_config_binary_file=$OUTPUT_DIR/l3-fwd_sem.pb.bin ``` ## 5. Start Infrap4d @@ -229,8 +233,8 @@ Once the application is started, set the forwarding pipeline config using P4Runtime Client `p4rt-ctl` set-pipe command ```bash -$P4CP_INSTALL/bin/p4rt-ctl set-pipe br0 $OUTPUT_DIR/simple_l3_l4_pna.pb.bin \ - $OUTPUT_DIR/simple_l3_l4_pna.p4info.txt +$P4CP_INSTALL/bin/p4rt-ctl set-pipe br0 $OUTPUT_DIR/l3-fwd_sem.pb.bin \ + $OUTPUT_DIR/l3-fwd_sem.p4info.txt ``` ## 7. Configure forwarding rule diff --git a/docs/guides/security/security-guide.md b/docs/guides/security/security-guide.md index 1a6fc64a..12672c4e 100644 --- a/docs/guides/security/security-guide.md +++ b/docs/guides/security/security-guide.md @@ -61,7 +61,7 @@ issue requests to port 9339. To launch infrap4d in insecure mode: ```bash -$IPDK_RECIPE/install/sbin/infrap4d -grpc_open_insecure_mode=true +infrap4d -grpc_open_insecure_mode=true ``` To launch clients in insecure mode: @@ -69,13 +69,11 @@ To launch clients in insecure mode: For DPDK target: ```bash -$IPDK_RECIPE/install/bin/gnmi-ctl set \ - -grpc_use_insecure_mode=true +gnmi-ctl set -grpc_use_insecure_mode=true ``` For Intel IPU E2100 target: ```bash -$IPDK_RECIPE/install/bin/sgnmi_cli set \ - -grpc_use_insecure_mode=true +sgnmi_cli set -grpc_use_insecure_mode=true ``` diff --git a/docs/guides/security/using-tls-certificates.md b/docs/guides/security/using-tls-certificates.md index a53fcfc1..6c954a89 100644 --- a/docs/guides/security/using-tls-certificates.md +++ b/docs/guides/security/using-tls-certificates.md @@ -24,6 +24,14 @@ COMMON_NAME= ./generate-certs.sh The system relies on mTLS (mutual TLS) for authentication. +### OpenSSL version + +The `/usr/share/stratum/generate-certs.sh` script uses the installed OpenSSL version to generate the certificates. + +OpenSSL 1.1.1x has reached EOL and usage should be discontinued. See the [OpenSSL security guide](openssl-guide.md) for details. + +Also, note that if running gRPC clients on remote system, both systems should be running OpenSSL 3.x. Running an OpenSSL 1.1.1x client with a OpenSSL 3.x server has been known to fail TLS handshakes with `WRONG_VERSION_NUMBER` error when trying to establish communication. + ## Installing certificates `infrap4d` will check for server certificates in the default location @@ -37,29 +45,6 @@ default location `/usr/share/stratum/certs/` to the server running infrap4d. Copy the generated `ca.crt`, `client.crt`, and `client.key` in the default location `/usr/share/stratum/certs/` to the client machine. -### Non-default location - -If you would like to use a different location for the server certificates, -copy the certifactes to the location and specify the following options on -the `infrap4d` command line. - -Option | Description ----------------------- | ------------------- --ca_cert_file=PATH | CA certificate file --server_cert_file=PATH | Server certificate file --server_key_file=PATH | Server private key file - -For example, start infrap4d with certificates in `/tmp/certs`: - -```bash -$P4CP_INSTALL/sbin/infrap4d \ - -ca_cert_file=/tmp/certs/ca.crt \ - -server_cert_file=/tmp/certs/stratum.crt \ - -server_key_file=/tmp/certs/stratum.key -``` - -Note: Client certificates must be installed in `/usr/share/stratum/certs`. - For more details about available options with respect to running infrap4d and clients in insecure mode and default behavior, see the [security_guide](security-guide.md). diff --git a/docs/guides/setup/dpdk-setup-guide.md b/docs/guides/setup/dpdk-setup-guide.md index c54af0b6..8310dfe3 100644 --- a/docs/guides/setup/dpdk-setup-guide.md +++ b/docs/guides/setup/dpdk-setup-guide.md @@ -68,16 +68,15 @@ the build system and helper scripts. Clone the repository used to build P4 Control Plane: ```bash -git clone --recursive https://github.com/ipdk-io/networking-recipe.git ipdk.recipe -cd ipdk.recipe +git clone --recursive https://github.com/ipdk-io/networking-recipe.git p4cp.recipe +cd p4cp.recipe export P4CP_RECIPE=`pwd` ``` ### Compile the recipe ```bash -cd $P4CP_RECIPE -./make-all.sh --target=dpdk --rpath +$P4CP_RECIPE/make-all.sh --target=dpdk --rpath ``` By default, make-all.sh will create an `install` folder in the networking-recipe diff --git a/docs/guides/setup/es2k-setup-guide.md b/docs/guides/setup/es2k-setup-guide.md index 52222692..2dc9d016 100644 --- a/docs/guides/setup/es2k-setup-guide.md +++ b/docs/guides/setup/es2k-setup-guide.md @@ -84,8 +84,8 @@ the build system and helper scripts. Clone the repository used to build P4 Control Plane: ```bash -git clone --recursive https://github.com/ipdk-io/networking-recipe.git ipdk.recipe -cd ipdk.recipe +git clone --recursive https://github.com/ipdk-io/networking-recipe.git p4cp.recipe +cd p4cp.recipe export P4CP_RECIPE=`pwd` ``` @@ -157,16 +157,15 @@ the range with cfgqs-idx parameter. Total number of queues split between process ### Run the infrap4d daemon ```bash -cd $P4CP_RECIPE sudo $P4CP_INSTALL/sbin/infrap4d ``` *Note*: By default, infrap4d runs in detached mode. If you want to run in -attached mode, specify the --nodetach command-line option. +attached mode, specify the `--nodetach` command-line option. - All infrap4d logs are by default logged under `/var/log/stratum`. - All P4SDE logs are logged in `p4_driver.log` under `$P4CP_RECIPE`. -*-All OVS logs are logged under `/tmp/ovs-vswitchd.log`. +- All OVS logs are logged under `/tmp/ovs-vswitchd.log`. ### Run a sample program diff --git a/docs/guides/setup/tofino-setup-guide.md b/docs/guides/setup/tofino-setup-guide.md index 208d51c5..fa819f07 100644 --- a/docs/guides/setup/tofino-setup-guide.md +++ b/docs/guides/setup/tofino-setup-guide.md @@ -35,7 +35,9 @@ docker run --privileged --cap-add=ALL -it --name infrap4d --network host -d ubun Clone IPDK networking-recipe: ```bash -git clone --recursive git@github.com:ipdk-io/networking-recipe.git ipdk.recipe +git clone --recursive git@github.com:ipdk-io/networking-recipe.git p4cp.recipe +cd p4cp.recipe +export P4CP_RECIPE=`pwd` ``` Clone the repository used to build the Stratum dependencies: @@ -101,19 +103,18 @@ Not that `bsp-path` is not required for tofino-model. ### Build Networking Recipe ```bash -cd $IPDK_RECIPE -./make-all.sh --target=tofino --deps=/usr/local +$P4CP_RECIPE/make-all.sh --target=tofino --deps=/usr/local ``` ## Run ```bash -cd IPDK_RECIPE -cp $SDE_INSTALL/share/bf_switchd/zlog-cfg $IPDK_RECIPE/zlog-cfg-cur +cd P4CP_RECIPE +cp $SDE_INSTALL/share/bf_switchd/zlog-cfg $P4CP_RECIPE/zlog-cfg-cur mkdir -p /etc/stratum/ mkdir -p /var/log/stratum/ -LD_LIBRARY_PATH=$IPDK_RECIPE/install/lib/:$SDE_INSTALL/lib \ +LD_LIBRARY_PATH=$P4CP_RECIPE/install/lib/:$SDE_INSTALL/lib \ ./install/sbin/infrap4d \ -chassis_config_file=./stratum/stratum/stratum/hal/config/x86-64-accton-wedge100bf-32x-r0/chassis_config.pb.txt \ -tdi_switchd_cfg=$SDE_INSTALL/share/p4/targets/tofino/tofino_skip_p4.conf \ @@ -161,8 +162,8 @@ To generate the bin file for the controller. ```bash cd $SDE_INSTALL -LD_LIBRARY_PATH=$IPDK_RECIPE/install/lib/:$SDE_INSTALL/lib \ - $IPDK_RECIPE/install/bin/tdi_pipeline_builder \ +LD_LIBRARY_PATH=$P4CP_RECIPE/install/lib/:$SDE_INSTALL/lib \ + $P4CP_RECIPE/install/bin/tdi_pipeline_builder \ -p4c_conf_file=$SDE_INSTALL/share/p4/targets/tofino/tna_exact_match.conf \ - -bf_pipeline_config_binary_file=$IPDK_RECIPE/tna_exact_match.pb.bin + -bf_pipeline_config_binary_file=$P4CP_RECIPE/tna_exact_match.pb.bin ``` diff --git a/ovs-p4rt/ovs_p4rt.cc b/ovs-p4rt/ovs_p4rt.cc index 95cd94e2..314c9921 100644 --- a/ovs-p4rt/ovs_p4rt.cc +++ b/ovs-p4rt/ovs_p4rt.cc @@ -177,25 +177,6 @@ void PrepareFdbTxVlanTableEntry(p4::v1::TableEntry* table_entry, ACTION_REMOVE_VLAN_AND_FWD_PARAM_VLAN_PTR)); param->set_value(EncodeByteValue(1, learn_info.vlan_info.port_vlan)); } - } else if (learn_info.vlan_info.port_vlan_mode == - P4_PORT_VLAN_NATIVE_TAGGED) { - action->set_action_id( - GetActionId(p4info, L2_FWD_TX_TABLE_ACTION_ADD_VLAN_AND_FWD)); - { - auto param = action->add_params(); - param->set_param_id(GetParamId(p4info, - L2_FWD_TX_TABLE_ACTION_ADD_VLAN_AND_FWD, - ACTION_ADD_VLAN_AND_FWD_PARAM_PORT_ID)); - auto port_id = learn_info.src_port; - param->set_value(EncodeByteValue(1, port_id)); - } - { - auto param = action->add_params(); - param->set_param_id(GetParamId(p4info, - L2_FWD_TX_TABLE_ACTION_ADD_VLAN_AND_FWD, - ACTION_ADD_VLAN_AND_FWD_PARAM_VLAN_PTR)); - param->set_value(EncodeByteValue(1, learn_info.vlan_info.port_vlan)); - } } else { action->set_action_id(GetActionId(p4info, L2_FWD_TX_TABLE_ACTION_L2_FWD)); { @@ -226,6 +207,7 @@ void PrepareFdbTxVlanTableEntry(p4::v1::TableEntry* table_entry, return; } +#if defined(ES2K_TARGET) void PrepareFdbRxVlanTableEntry(p4::v1::TableEntry* table_entry, const struct mac_learning_info& learn_info, const ::p4::config::v1::P4Info& p4info, @@ -237,7 +219,6 @@ void PrepareFdbRxVlanTableEntry(p4::v1::TableEntry* table_entry, std::string mac_addr = CanonicalizeMac(learn_info.mac_addr); match->mutable_exact()->set_value(mac_addr); -#if defined(ES2K_TARGET) // Based on p4 program for ES2K, we need to provide a match key Bridge ID auto match1 = table_entry->add_match(); match1->set_field_id( @@ -251,7 +232,6 @@ void PrepareFdbRxVlanTableEntry(p4::v1::TableEntry* table_entry, L2_FWD_RX_TABLE_KEY_SMAC_LEARNED)); match2->mutable_exact()->set_value(EncodeByteValue(1, 1)); -#endif if (insert_entry) { auto table_action = table_entry->mutable_action(); @@ -261,13 +241,7 @@ void PrepareFdbRxVlanTableEntry(p4::v1::TableEntry* table_entry, auto param = action->add_params(); param->set_param_id(GetParamId(p4info, L2_FWD_RX_TABLE_ACTION_L2_FWD, ACTION_L2_FWD_PARAM_PORT)); -#if defined(DPDK_TARGET) - auto port_id = learn_info.vln_info.vlan_id - 1; -#elif defined(ES2K_TARGET) auto port_id = learn_info.src_port; -#else - auto port_id = 0; -#endif param->set_value(EncodeByteValue(1, port_id)); } } @@ -275,6 +249,35 @@ void PrepareFdbRxVlanTableEntry(p4::v1::TableEntry* table_entry, return; } +#elif defined(DPDK_TARGET) +void PrepareFdbRxVlanTableEntry(p4::v1::TableEntry* table_entry, + const struct mac_learning_info& learn_info, + const ::p4::config::v1::P4Info& p4info, + bool insert_entry) { + table_entry->set_table_id(GetTableId(p4info, L2_FWD_RX_WITH_TUNNEL_TABLE)); + auto match = table_entry->add_match(); + match->set_field_id(GetMatchFieldId(p4info, L2_FWD_RX_WITH_TUNNEL_TABLE, + L2_FWD_TX_TABLE_KEY_DST_MAC)); + std::string mac_addr = CanonicalizeMac(learn_info.mac_addr); + match->mutable_exact()->set_value(mac_addr); + + if (insert_entry) { + auto table_action = table_entry->mutable_action(); + auto action = table_action->mutable_action(); + action->set_action_id(GetActionId(p4info, L2_FWD_TX_TABLE_ACTION_L2_FWD)); + { + auto param = action->add_params(); + param->set_param_id(GetParamId(p4info, L2_FWD_RX_TABLE_ACTION_L2_FWD, + ACTION_L2_FWD_PARAM_PORT)); + auto port_id = learn_info.vln_info.vlan_id - 1; + param->set_value(EncodeByteValue(1, port_id)); + } + } + + return; +} +#endif + void PrepareFdbTableEntryforV4Tunnel(p4::v1::TableEntry* table_entry, const struct mac_learning_info& learn_info, const ::p4::config::v1::P4Info& p4info, diff --git a/ovs/ovs b/ovs/ovs index 742e51ee..8ae0569d 160000 --- a/ovs/ovs +++ b/ovs/ovs @@ -1 +1 @@ -Subproject commit 742e51ee30943eb2033b3e88163d691a5d89bc07 +Subproject commit 8ae0569d3f18f35d995c511391db8175fbdc3398 diff --git a/scripts/common/setup_env.sh b/scripts/common/setup_env.sh index 25ff380f..b5f9eb4e 100755 --- a/scripts/common/setup_env.sh +++ b/scripts/common/setup_env.sh @@ -37,11 +37,12 @@ echo "${OS} : ${VER}" # Update SDE libraries export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${SDE_INSTALL}/lib -export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${SDE_INSTALL}/lib64 -if [ "$OS" = "Fedora" ]; then +if [ -d ${SDE_INSTALL}/lib64 ]; then export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${SDE_INSTALL}/lib64 -else +fi + +if [ -d ${SDE_INSTALL}/lib/x86_64-linux-gnu ]; then export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${SDE_INSTALL}/lib/x86_64-linux-gnu fi diff --git a/stratum/stratum b/stratum/stratum index 92853543..b987441a 160000 --- a/stratum/stratum +++ b/stratum/stratum @@ -1 +1 @@ -Subproject commit 92853543b8d2c9b9d1789208e20aae2cda53b976 +Subproject commit b987441afd34b740685aedc8164fd07a7aee0d99