[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191024143651.795705df@cakuba.hsd1.ca.comcast.net>
Date: Thu, 24 Oct 2019 14:36:51 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Saeed Mahameed <saeedm@...lanox.com>
Cc: "David S. Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Tariq Toukan <tariqt@...lanox.com>
Subject: Re: [net 11/11] Documentation: TLS: Add missing counter description
On Thu, 24 Oct 2019 19:39:02 +0000, Saeed Mahameed wrote:
> From: Tariq Toukan <tariqt@...lanox.com>
>
> Add TLS TX counter description for the packets that skip the resync
> procedure and handled in the regular transmit flow, as they contain
> no data.
>
> Fixes: 46a3ea98074e ("net/mlx5e: kTLS, Enhance TX resync flow")
> Signed-off-by: Tariq Toukan <tariqt@...lanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>
> ---
> Documentation/networking/tls-offload.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst
> index 0dd3f748239f..87db87099607 100644
> --- a/Documentation/networking/tls-offload.rst
> +++ b/Documentation/networking/tls-offload.rst
> @@ -436,6 +436,9 @@ by the driver:
> encryption.
> * ``tx_tls_ooo`` - number of TX packets which were part of a TLS stream
> but did not arrive in the expected order.
> + * ``tx_tls_skip_no_sync_data`` - number of TX packets which were part of
> + a TLS stream and arrived out-of-order, but skipped the HW offload routine
> + and went to the regular transmit flow as they contained no data.
That doesn't sound right. It sounds like you're talking about pure Acks
and other segments with no data. For mlx5 those are skipped directly in
mlx5e_ktls_handle_tx_skb().
This counter is for segments which are retransmission of data queued to
the socket before kernel got the keys installed.
You explained it reasonably well in 46a3ea98074e ("net/mlx5e: kTLS,
Enhance TX resync flow"):
However, in case the TLS SKB is a retransmission of the connection
handshake, it initiates the resync flow (as the tcp seq check holds),
while regular packet handle is expected.
Did this patch get stuck in the queue for so long you forgot what the
counter was? ;)
> * ``tx_tls_drop_no_sync_data`` - number of TX packets which were part of
> a TLS stream dropped, because they arrived out of order and associated
> record could not be found.
Powered by blists - more mailing lists