On 02/06/2020 21:27, Jakub Kicinski wrote: > On Tue, 2 Jun 2020 07:23:53 +0300 Boris Pismenny wrote: >> On 02/06/2020 1:12, Jakub Kicinski wrote: >>> On Sun, 31 May 2020 15:06:28 +0300 Boris Pismenny wrote: >>>> On 30/05/2020 0:50, Jakub Kicinski wrote: >>>> >>>>> IIUC every ooo packet causes a resync request in your >>>>> implementation - is that true? >>>>> >>>> No, only header loss. We never required a resync per OOO packet. I'm >>>> not sure why would you think that. >>> I mean until device is back in sync every frame kicks off >>> resync_update_sn() and tries to queue the work, right? >>> >> Nope, only the first frame triggers resync_update_sn, so as to keep >> the process efficient and avoid spamming the system with resync >> requests. Per-flow, the device will try again to trigger >> resync_update_sn only if it gets out of sync due to out-of-sequence >> record headers. > It'd be good to clarify what the ooo counter counts in the > documentation, it sounds like it counts first TLS header HW found > after seq discontinuity is detected? > > In fact calling this a ooo counter may be slightly misleading, I like > the nfp counters much more: tx_tls_resync_req_ok and > tx_tls_resync_req_ign.
I agree. We will add it to mlx5 and document.Thanks!
