diff options
| author | Stefano Brivio <sbrivio@redhat.com> | 2025-08-29 22:11:27 +0200 |
|---|---|---|
| committer | Stefano Brivio <sbrivio@redhat.com> | 2025-09-11 17:03:38 +0200 |
| commit | 1d502be1a809dcdc4614815f4ec0da77a1ff27ec (patch) | |
| tree | db66b7d4250f4ff017cfe465f0584d78e6b44794 /test/lib | |
| parent | 2e3d93ba7033754301af0d50cd0bb20a38a005ac (diff) | |
| download | passt-1d502be1a809dcdc4614815f4ec0da77a1ff27ec.tar passt-1d502be1a809dcdc4614815f4ec0da77a1ff27ec.tar.gz passt-1d502be1a809dcdc4614815f4ec0da77a1ff27ec.tar.bz2 passt-1d502be1a809dcdc4614815f4ec0da77a1ff27ec.tar.lz passt-1d502be1a809dcdc4614815f4ec0da77a1ff27ec.tar.xz passt-1d502be1a809dcdc4614815f4ec0da77a1ff27ec.tar.zst passt-1d502be1a809dcdc4614815f4ec0da77a1ff27ec.zip | |
tcp: Factor sequence rewind for retransmissions into a new function
...as I'm going to need a third occurrence of this in the next change.
This introduces a small functional change in tcp_data_from_tap(): the
sequence was previously rewound to the highest ACK number we found in
the current packet batch, and not to the current value of
seq_ack_from_tap.
The two might differ in case tcp_sock_consume() failed, because in
that case we're ignoring that ACK altogether. But if we're ignoring
it, it looks more correct to me to start retransmitting from an
earlier sequence anyway.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Diffstat (limited to 'test/lib')
0 files changed, 0 insertions, 0 deletions