V4-dev-bugs
V4 version of WR switch HDL shall include (at least) the following additional feature/modules:
- Per-Port statistics
- Endpoint events for PSTATS
- VLAN support
Known bugs/issues/things to do are listed below*
Summary table (details below)
ID | Name | State | Date | Remarks |
1 | VLANs and Fast Match and Full Match | Fixed but... | 20/08/2013 | ... the problem was RAM readout - it started to synthesize correctly but no direct cause of problem found -- I would like to try introducing pipelined MUX to make sure it works OK |
2 | Broadcast and unrecognized broadcast works for Full Match only if VID_0.mask=0xF....F | Fixed but... | 20/08/2013 | the problem was RAM readout - it started to synthesize correctly but no direct cause of problem found -- I would like to try introducing pipelined MUX to make sure it works OK |
3 | SWcore does not handle situation when the ingress frame is dropped while processing header | Fixed | 27/05/2013 | |
4 | Too slow forwarding (loosing frames with high load) | Progressed | 16/09/2013 | Fixed for simple case of only two ports connected, not tested for multi-connection |
5 | Normal" frames are lost when there is PTP running in the background | ToDo | 25/05/2013 | |
6 | The case where problem on port 5 affects unrelated traffic on port 1 | ToTest | 16/09/2013 | Probably connected with RAM readout ([1] & [2]) , not tested again |
7 | With high load and snake test frames are wrongly forwarded | ToTest | 16/09/2013 | Probably connected with RAM readout ([1] & [2]) , not tested again |
8 | "Ro-run" and "Rpcs-e" with small frames/high load | Progressed | 16/09/2013 | Not observed again, might have been fixed when fixing other stuff |
9 | Possibly HP traffic is not using HP resources | Fixed | 20/08/2013 | Need to verify/test |
10 | Priority vector/numbers seems to be reversed somewhere negated or does not work properly | Fixed | 25/07/2013 | |
11 | NonHP frame dropping on egress when HP is in the output queue does not seem to be working | ToDo | 25/05/2013 | |
12 | Priority-based configuration of HP traffic is not working correctly | Fixed | 19/08/2013 | not GW bug but SW misconfig !! |
13 | possible problem: linked-list in SWcore written faster then usecnt set in MMU | ToInvestigate | 10/10/2013 | I need to check whether this not create race condition where we start reading page with not usecnt set |
Detailed bug description
(1) VLANs and Fast Match and Full 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)
- It seems that Full Match has the same problem... HACK in tru_port_new.vhd to tmp-solve it! !!
(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
- (26/07/2013) seems, to be that the drop flag of VID=0 is read from RAM in the fast match, when using VID =! 0 for matching. This is rather some timing problem. It works when the RAM is read longer then one cycle -> this will cause problems with more intense traffic
(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: undefined, 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: undefined, 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: undefined, 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 - PSTATS and input_block SWcore's state dump of different test but similar problem:
- input_block SWcore's states (from Hardware Debugging Unit):
P | 0:Tu-run | 1:Ro-run | 2:Riv-cd | 3:Rsyn-l | 4:Rpause | 5:Rpf-dp | 6:Rpcs-e | 7:Rgiant | 8:Rrunt | 9:Rcrc_e | 10:Rpcl_0 | 11:Rpcl_1 | 12:Rpcl_2 | 13:Rpcl_3 | 14:Rpcl_4 | 15:Rpcl_5 | 16:Rpcl_6 | 17:Rpcl_7 | 18:Tframe | 19:Rframe | 20:Rrtu_f | 21:RTUreq | 22:RTUrsp | 23:RTUdrp | 24:RTUhp | 25:RTUf-f | 26:RTUn-f | 27:RTUfst | 28:RTUful | 29:RTUfwd |
0 | 0 | 1 | 0 | 0 | 0 | 0 | 2364 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1440241 | 100299722 | 0 | 100297349 | 100297349 | 0 | 0 | 0 | 0 | 100297349 | 100297349 | 89920586 |
1 | 0 | 1 | 0 | 0 | 0 | 0 | 431 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1440241 | 101096996 | 11110441 | 89920588 | 89920586 | 0 | 0 | 0 | 0 | 89920588 | 89920588 | 100428421 |
2 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2554350 | 102342236 | 13297461 | 89044774 | 89044772 | 0 | 0 | 0 | 0 | 89044774 | 89044774 | 2554350 |
3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2554352 | 2554350 | 0 | 2554350 | 2554350 | 0 | 0 | 0 | 0 | 2554350 | 2554350 | 89044772 |
4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1440238 | 1440240 | 0 | 1440240 | 1440240 | 0 | 0 | 0 | 0 | 1440240 | 1440240 | 1440238 |
5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1440239 | 1440238 | 0 | 1440238 | 1440238 | 0 | 0 | 0 | 0 | 1440238 | 1440238 | 1440240 |
6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2554350 | 2554351 | 0 | 2554351 | 2554351 | 0 | 0 | 0 | 0 | 2554351 | 2554351 | 2554352 |
7 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2554350 | 102342259 | 99591297 | 2554354 | 2554352 | 0 | 0 | 0 | 0 | 2554354 | 2554354 | 2554351 |
(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: undefined,
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 2 =>> alloc: undefined,
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 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: undefined,
trans_FSM: S_WAIT_WITH_TRANSFER, rcv_p_FSM: S_PAUSE, linkl_FSM:
S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=1
(I) [rtu_hwdu_drv.c:175] [HWDP] unknown resources, page cnt
:1014
(I) [rtu_hwdu_drv.c:176] [HWDP] high prio resources, page cnt :0
(I) [rtu_hwdu_drv.c:177] [HWDP] normal resources, page cnt :1023
- two potential problems:
** got lost with rtu rsp/ack (trans_FSM: S_WAIT_RTU_VALID)
** memory allocation FSM stuck (alloc: undefined)
- 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: undefined, 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
-
NIC's "hp" bit of rtu faked response is not connected -> this might be a problem
-
changing config of "When fast match engine too slow" from "drop processed frame" to "braodcast processed frame"
(6) The case where problem on port 5 affects unrelated traffic on port 1
| P | 0:Tu-run| 1:Ro-run| 2:Riv-cd| 3:Rsyn-l| 4:Rpause| 5:Rpf-dp|
6:Rpcs-e| 7:Rgiant| 8:Rrunt
|
9:Rcrc_e|10:Rpcl_0|11:Rpcl_1|12:Rpcl_2|13:Rpcl_3|14:Rpcl_4|15:Rpcl_5|16:Rpcl_6|17:Rpcl_7|18:Tframe|19:Rframe|20:Rrtu_f|21:RTUreq|22:RTUrsp|23:RTUdrp|24:RTUhp
|25:RTUf-f|26:RTUn-f|27:RTUfst|28:RTUful|29:RTUfwd|
| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 19687335|
19687335| 0| 19687335| 19817588| 2569| 0| 0| 0| 19687335| 19818049|
19687335|
| 1| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 19683947|
19687335| 0| 19687335| 19687335| 0| 0| 0| 0| 19687335| 19687335|
19683947|
| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 12608805|
25388967| 0| 25388967| 25388967| 0| 0| 0| 0| 25388967| 25388967|
12608805|
| 3| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23029671|
10250687| 0| 10250687| 10250602| 1093| 0| 0| 0| 10250687| 10250621|
23029671|
| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 6515135|
19556263| 0| 19556263| 19490671| 1244| 0| 0| 0| 19556263| 19490678|
6515137|
| 5| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 19882643|
19883018| 13234855| 6517091| 6516634| 1497| 0| 0| 0| 6517091| 6516882|
19882643|
| 6| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 21718026|
21717651| 0| 21717651| 21586276| 2893123| 0| 0| 0| 21717651| 21651949|
21718026|
| 7| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 23018528|
25847719| 0| 25847719| 25912880| 550| 0| 0| 0| 25847719| 25847627|
23018529|
(7) With high load and snake test frames are wrongly forwarded
- snake test for 6 and 16 ports + separate stream on first two ports
- at some point, forwarding gets lots and there is a forwarding mess
- this might case losses of pages
- see bug (8) for debugging dump of test of 6-port-snake and 2-port HP traffic (note that HP ports seem to be OK, but data was lost), test ref: Test: T12_TS7_SWC6_SPC1->T12.2
(8) "Ro-run" and "Rpcs-e" with small frames/high load
- interestingly the HP ports do not get lost and no HP pages lost but we have problems with "Ro-run" and "Rpcs-e"
- test ref: Test: T12_TS7_SWC6_SPC1->T12.2
P | 0:Tu-run | 1:Ro-run | 2:Riv-cd | 3:Rsyn-l | 4:Rpause | 5:Rpf-dp | 6:Rpcs-e | 7:Rgiant | 8:Rrunt | 9:Rcrc_e | 10:Rpcl_0 | 11:Rpcl_1 | 12:Rpcl_2 | 13:Rpcl_3 | 14:Rpcl_4 | 15:Rpcl_5 | 16:Rpcl_6 | 17:Rpcl_7 | 18:Tframe | 19:Rframe | 20:Rrtu_f | 21:RTUreq | 22:RTUrsp | 23:RTUdrp | 24:RTUhp | 25:RTUf-f | 26:RTUn-f | 27:RTUfst | 28:RTUful | 29:RTUfwd |
0 | 0 | 1 | 0 | 0 | 0 | 0 | 2162 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 19537412 | 62913498 | 0 | 62911327 | 62911327 | 0 | 62911327 | 62911327 | 0 | 62911327 | 58139855 | 62911280 |
1 | 0 | 1 | 0 | 0 | 0 | 0 | 2378 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 18943023 | 61930501 | 0 | 61928114 | 61928114 | 0 | 61928114 | 61928114 | 0 | 61928114 | 61155843 | 61862878 |
2 | 0 | 1 | 0 | 0 | 0 | 0 | 693 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 17316353 | 69080478 | 8656871 | 60291842 | 60355189 | 11949867 | 0 | 0 | 0 | 60291842 | 60291236 | 17316353 |
3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 23669721 | 15454945 | 0 | 15454945 | 15454578 | 38760 | 9 | 9 | 0 | 15454945 | 15454599 | 41851722 |
4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 12440289 | 20458457 | 0 | 20458457 | 20458269 | 3649712 | 49 | 49 | 0 | 20458457 | 20458427 | 21008571 |
5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 14389897 | 24778224 | 0 | 24778224 | 24741313 | 3798259 | 19 | 19 | 0 | 24778224 | 24778176 | 17005116 |
6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 26482160 | 16290441 | 0 | 16290441 | 16285803 | 45698 | 83 | 83 | 0 | 16290441 | 16288598 | 40505085 |
7 | 0 | 1 | 0 | 0 | 0 | 0 | 10 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 18794187 | 70132869 | 13026448 | 57106411 | 56944841 | 12114380 | 0 | 0 | 0 | 57106411 | 57035878 | 20237747 |
(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: undefined,
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 3 =>> alloc: S_IDLE,
trans_FSM: S_WAIT_RTU_VALID, rcv_p_FSM: S_IDLE, 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_WAIT_RTU_VALID, rcv_p_FSM: S_IDLE, 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_WAIT_RTU_VALID, rcv_p_FSM: S_IDLE, 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_WAIT_RTU_VALID, rcv_p_FSM: S_IDLE, linkl_FSM:
S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0
(I) [rtu_hwdu_drv.c:204] [HWDP] port 7 =>> alloc: undefined,
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:175] [HWDP] unknown resources, page cnt :406
(I) [rtu_hwdu_drv.c:176] [HWDP] high prio resources, page cnt :0
(I) [rtu_hwdu_drv.c:177] [HWDP] normal resources, page cnt :641
(9) Possibly HP traffic is not using HP resources
- a test (ref:) which should be using HP resources and caused the switch to get completely lost...
- memory dump shows that no HP pages were lost:
(I) [rtu_hwdu_drv.c:175] [HWDP] unknown resources, page cnt :357
(I) [rtu_hwdu_drv.c:176] [HWDP] high prio resources, page cnt :0
(I) [rtu_hwdu_drv.c:177] [HWDP] normal resources, page cnt :970 - all the ports are very lost:
(I) [rtu_hwdu_drv.c:204] [HWDP] port 0 =>> alloc: S_IDLE, trans_FSM: S_WAIT_SOF, 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_WAIT_SOF, 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_WAIT_SOF, 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_WAIT_SOF, rcv_p_FSM: S_READY, linkl_FSM: S_READY_FOR_PGR_AND_DLAST, rtu_rsp_valid=0 - hp traffic was used:
P | 0:Tu-run | 1:Ro-run | 2:Riv-cd | 3:Rsyn-l | 4:Rpause | 5:Rpf-dp | 6:Rpcs-e | 7:Rgiant | 8:Rrunt | 9:Rcrc_e | 10:Rpcl_0 | 11:Rpcl_1 | 12:Rpcl_2 | 13:Rpcl_3 | 14:Rpcl_4 | 15:Rpcl_5 | 16:Rpcl_6 | 17:Rpcl_7 | 18:Tframe | 19:Rframe | 20:Rrtu_f | 21:RTUreq | 22:RTUrsp | 23:RTUdrp | 24:RTUhp | 25:RTUf-f | 26:RTUn-f | 27:RTUfst | 28:RTUful | 29:RTUfwd |
0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 3238398 | 2925882 | 82631 | 2843251 | 2843251 | 0 | 2843251 | 2843251 | 0 | 2843251 | 2843251 | 4203916 |
1 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2976297 | 2925882 | 82631 | 2843251 | 2843251 | 0 | 2843251 | 2843251 | 0 | 2843251 | 2843251 | 4007349 |
2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2729274 | 82631 | 2646643 | 2646643 | 0 | 0 | 0 | 0 | 2646643 | 2646643 | 0 |
3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2729274 | 82631 | 2646643 | 2646643 | 0 | 0 | 0 | 0 | 2646643 | 2646643 | 0 |
4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
7 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
(10) Priority vector/numbers seems to be reversed somewhere negated or does not work properly
- when setting HP traffic to be 7, it affects traffic which is tagged on ingress (Endpoint VLAN tagging) with fixed priority of value 0
(11) nonHP frame dropping on egress when HP is in the output queue does not seem to be working or is very slow
(12) Priority-based configuration of HP traffic is not working correctly
- works for all priorities and non-tagged frames (probably by luck): assigns traffic as HP for prio=0xff
- works for no HP assignment: prio=0x00
- problem when defining only one priority as HP -> assigns all frames as HP, should only one prio -> when prio[0]=1 it assigns HP to all, if prio[0]=0, it does not assign HP at all
my notes when developing:
- swcore->dropping does not work well
- drop when FULL_MATCH and new frame coming -> does not work
- todo
- add to the alloc-core to resource management-> need to adapt the resource_manager
- probably the same reason for drop@highPrio
- check usecase 70 -> s_rcv_pck FSM goes into S_PAUSE shortly -> not good