diff options
author | Steven Luong <sluong@cisco.com> | 2022-08-29 10:00:31 -0700 |
---|---|---|
committer | Damjan Marion <dmarion@0xa5.net> | 2022-08-30 18:12:03 +0000 |
commit | fcb2132d74627178a5a83fabd0addf741654fe63 (patch) | |
tree | 3827e8414ebcbd54b74d3a3650b258da7bcf150d /src/vlibmemory/memclnt_api.c | |
parent | 76b8aa00f73390aba91d075125c51b4af6c48ebb (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