summaryrefslogtreecommitdiffstats
path: root/src/vlibmemory/memclnt_api.c
diff options
context:
space:
mode:
authorSteven Luong <sluong@cisco.com>2022-08-29 10:00:31 -0700
committerDamjan Marion <dmarion@0xa5.net>2022-08-30 18:12:03 +0000
commitfcb2132d74627178a5a83fabd0addf741654fe63 (patch)
tree3827e8414ebcbd54b74d3a3650b258da7bcf150d /src/vlibmemory/memclnt_api.c
parent76b8aa00f73390aba91d075125c51b4af6c48ebb (diff)
memif: Process bad descriptors correctly in memif_process_desc
When there is a bad descriptor, it may in the beginning, in the middle, or at the end of the batch if the batch has more than 3 descriptors. When processing a bad descriptor is encountered in the batch, we need to rollback n_buffers in memif_process_desc(), or the statement in the same function memif_add_copy_op (ptd, mb0 + src_off, bytes_to_copy, dst_off, n_buffers - 1); is wrong because it picks up the wrong buffer_vec_index of the bad descriptor while parsing a good descriptor immediately following the bad descriptor. n_buffers was incremented in the beginning of while (n_left) loop. The other problem is we should count the number of bad packets and reduce ptd->n_packets to get the correct number of packets for subsequent processing in device_input. The last fix is to check if n_buffers == 0 in device_input and skip doing any descriptor copy. This case can happen when all the descriptors are bad in the batch. Type: fix Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: I28ed1d87236b045657006755747b5750a9a733be
Diffstat (limited to 'src/vlibmemory/memclnt_api.c')
0 files changed, 0 insertions, 0 deletions