>>
>> Yes, although I would phrase it differently: the kernel would indicate to
>> the driver,
>> that the resync request is wrong, and that it can go back to searching for a
>> header.
>> If there are any drivers that need an extra check, then we can add it in the
>> driver itself.
>
> I'd rat
On Thu, 28 May 2020 09:03:07 +0300 Boris Pismenny wrote:
> On 20/05/2020 23:34, Jakub Kicinski wrote:
> > On Wed, 20 May 2020 18:14:08 +0300 Tariq Toukan wrote:
> >> From: Boris Pismenny
> >>
> >> In driver request resync, the hardware requests a resynchronization
> >> request at some TCP sequen
On 20/05/2020 23:34, Jakub Kicinski wrote:
> On Wed, 20 May 2020 18:14:08 +0300 Tariq Toukan wrote:
>> From: Boris Pismenny
>>
>> In driver request resync, the hardware requests a resynchronization
>> request at some TCP sequence number. If that TCP sequence number does
>> not point to a TLS rec
On Wed, 20 May 2020 18:14:08 +0300 Tariq Toukan wrote:
> From: Boris Pismenny
>
> In driver request resync, the hardware requests a resynchronization
> request at some TCP sequence number. If that TCP sequence number does
> not point to a TLS record header, then the resync attempt has failed.
>
From: Boris Pismenny
In driver request resync, the hardware requests a resynchronization
request at some TCP sequence number. If that TCP sequence number does
not point to a TLS record header, then the resync attempt has failed.
Failed resync should reset the resync request to avoid spurious res
