On Wed, 3 Jun 2020 10:02:33 +0300 Tariq Toukan wrote:

quoted

IIUC the HW asks for a resync at the first record after a specific seq
(the record header is in the frame that carried the OOO marking, right?)

Can we make the core understand those semantics and avoid trying to
resync at the wrong record?

HW asks for a resync when it is in tracking mode and identifies the 
magic, so it calculates the expected seq of next record.
This seq is not part of the completion (for now, this is a planned 
enhancement), so the device driver posts a request to the device to get 
the seq, and then the driver hopefully approve it (by another post to 
the HW) after comparing it to the stack sw seq.

As long as the device driver does not know the HW expected seq, it 
cannot provide a seq to the stack. So force resync is used.

Right, what I was trying to say is that the HW will likely latch on the
first magic in the TCP segment, so maybe the driver and the core can
reasonably expect that. Driver can tell the core to provide first
record after TCP seq_no X. Otherwise if the TCP socket is backed up
driver may get a very old record.

Just clarifying what I was trying to say, not sure how that fits your
device.

We can think of an optimization here, it is doable.