V4-dev-bugs
(1) VLANs and Fast Match
Fast Forward (FF) which uses only Fast Match (Single MAC, MAC Range, Broadcast) works only for mask of VID=0
- I set the following configuration:
Port 0: ingress tag to VID=FID=0
Port 1: ingress tag to VID=FID=0
Port 2: ingress tag to VID=FID=1
Port 3: ingress tag to VID=FID=1
Port 4: ingress tag to VID=FID=2
Port 5: ingress tag to VID=FID=2
Port 6: ingress tag to VID=FID=3
Port 7: ingress tag to VID=FID=3 - VLAN masks:
VID_0.mask = 0x3
VID_1.mask = 0xc
VID_2.mask = 0x30
VID_3.mask = 0xc0 - FF traffic sent to any port (VLAN), is forwarded only to Ports 0 and 1 (VID=0)
(2) Broadcast and unrecognized broadcast works for Full Match works only if VID_0.mask=0xF....F
This is because of (1):
- traffic is dropped because the Fast Match is returning different mask then Full Match,
- the mask of Fast Match and Full Match are ANDed, the result is zero mask and the decision is drop
(3) [fixed] SWcore does not handle situation when the ingress frame is dropped while processing header
- trans_FSM of input_block of SWcore gets stuck at state: S_WAIT_RTU_VALID
- this happens when unplugging the cable and the frame gets corrupted around header
- the SWcore starts receiving data, so it waits for decision from RTU
- since the frame is corrupted at the header, Endpoint never sends request to RTU, therefore there is no decision passed to SWcore
- this situation was not foreseen
(4) Too slow forwarding (loosing frames with high load)
- size: 64 bytes, load up to 90% (ports 2,4,6,8, point-to-point
streams)
- input_block SWcore's states (from Hardware Debugging Unit):
(I) [rtu_hwdu_drv.c:204] [HWDP] port 0 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 1 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 2 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 3 =>> alloc: fucked, trans_FSM: S_WAIT_RTU_VALID, rcv_p_FSM: S_IDLE, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=1
(I) [rtu_hwdu_drv.c:204] [HWDP] port 4 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 5 =>> alloc: fucked, trans_FSM: S_WAIT_RTU_VALID, rcv_p_FSM: S_IDLE, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=1
(I) [rtu_hwdu_drv.c:204] [HWDP] port 6 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 7 =>> alloc: fucked, trans_FSM: S_WAIT_RTU_VALID, rcv_p_FSM: S_IDLE, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=1 - MultiPort Memory (MPM) page count dump:
(I) [rtu_hwdu_drv.c:175] [HWDP] unknown resources, page cnt :923
(I) [rtu_hwdu_drv.c:176] [HWDP] high prio resources, page cnt :0
(I) [rtu_hwdu_drv.c:177] [HWDP] normal resources, page cnt :116 - two potential problems:
- got lost with rtu rsp/ack (trans_FSM: S_WAIT_RTU_VALID)
- memory allocation FSM stuck (alloc: fucked)
- input_block SWcore's states (from Hardware Debugging Unit):
- size: 128 bytes, load up to 90% (ports 2,4,6,8, point-to-point
streams)
- input_block SWcore's states (from Hardware Debugging Unit):
(I) [rtu_hwdu_drv.c:204] [HWDP] port 0 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 1 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 2 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 3 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 4 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 5 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 6 =>> alloc: S_IDLE, trans_FSM: S_READY, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 7 =>> alloc: fucked, trans_FSM: S_WAIT_WITH_TRANSFER, rcv_p_FSM: S_PAUSE, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=1 - MultiPort Memory (MPM) page count dump:
(I) [rtu_hwdu_drv.c:175] [HWDP] unknown resources, page cnt :24
(I) [rtu_hwdu_drv.c:176] [HWDP] high prio resources, page cnt :0
(I) [rtu_hwdu_drv.c:177] [HWDP] normal resources, page cnt :1020 - two potential problems:
- different problem then with 64 bytes size
- one port seems to cause all traffic to get lost
- input_block SWcore's states (from Hardware Debugging Unit):
(5) "Normal" frames are lost when there is PTP running in the background
- PTP frames are sent with 0 priority (so should have no effect)
- Normal traffic sent - no VLAN tagging
- we loss ~ 10-100 "normal" frames (out of 1-16*10^6)
- max latency for the forwarded "normal" frames is very stable