Closed chenxuqiang closed 5 months ago
Why is there no error in the original SHA1_MB_CE_MAX_LANES==2
? After the test, we find that the same problem occurs, but the infinite loop is not triggered:
...
0 update
0, 1047488, 1088
1 update
1, 1048320, 256 # buffer1 update with LAST
0 update
0, 1048320, 256 # buffer0 update with LAST
i = 0 completed.
1, 1048320, 256 # buffer1 is submitted twice
i = 1 completed. # It's just that because buffer1 is also completed, there's no infinite loop.
...
This is now fixed, thanks!
I found that SHA1 MultiBuffer is blocking in
sha1_mb_rand_update_test
when theSHA1_MB_CE_MAX_LANES
is greater than 2. According to thelen_done
andlen_rem
information, whenlen_rem == 256
, the expected value ofLAST
flag is submitted, and the calculation of this flow ends. However, the test result shows that lane1'slen_rem
becomes a negative number and continues to execute the calculation. As a result, an infinite loop occurs.After further log analysis, we find that when lanes==3, the update sequence is as follows:
Therefore, the last commit is
lanes == 0 (i== 0)
. In this case,i++
->i == 1
, but the last request with lanes=1 has been committed. As a result, lem_rem becomes a negative number and an infinite loop occurs.The expected order of submission should be as follows:
The last submitted request should be
i==2
. In this case,i++ == 3
can exit the loop (whenTEST_BUFS==3
) or commit new lane's request (whenTEST_BUFS>3
).So what's the problem? I found the problem in the implementation of
sha1_mb_mgr_init_ce
insha1_mb_mgr_ce.c
:Lane_idx array after initialization: [0, 1, 2], When the
sha1_mb_mgr_insert_job
operation is called,lane_idx
is allocated from right to left. The obtained lane_idx is 2, 1, and 0. Therefore, the first returned request is the value of the first lane_idx position, which is 2. Therefore, the request ofbuffer0
is inserted intolane_idx=2
. Whensha1_mb_mgr_free_lane
is called,lane_idx: 0~2
is traversed. Therefore, the result of the last commit,buffer2
, is returned instead of the expectedbuffer0
. So there's:The correct method is to initialize unsed_lanes to [2, 1, 0], just like the other modules' MGR , such as
sha256_mb_mgr_init_ce
orsha1_mb_mgr_init_asimd
.