From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a2-smtp.messagingengine.com (fhigh-a2-smtp.messagingengine.com [103.168.172.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4E474A13A2 for ; Wed, 6 May 2026 17:07:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.153 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778087262; cv=none; b=UbhcgJNFkzhA+r04RmOUsKG5HsqC/hY01eLGHub/cy+HYApbwOKwUknThQ8pzHtWnqK29NoBb5IaSG5VBNdDkzbICRyXiz6tTOsFr8i2qQE5df+6KWbR7Ajs7Df2CV8SwMjKNshrnKNNqtxE+EK08K7LYR0oGx4uEhVqmzHK1Wg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778087262; c=relaxed/simple; bh=nbN/QaHyJkxc9D1I5v6/xaZXd/O9cJWCUJL3XzW7x+k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sLeebQTKsLIh3CINK69TpS6g2wKtmgctFleFt5nknAEUUvmTJS0eM/lPejofjjaB/yIUvjIrXfcGIuq6634634PxNaCPI2gpKEXTKaRaqw7d5ufaGhFW/KwihVHwASiTybI+6yoah9AmZDAxpFdb7Hv+DgNXGmle3PLwCGCZhQ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net; spf=pass smtp.mailfrom=queasysnail.net; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b=sF2AKF7Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=rrf7ZRyY; arc=none smtp.client-ip=103.168.172.153 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b="sF2AKF7Y"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="rrf7ZRyY" Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfhigh.phl.internal (Postfix) with ESMTP id F26941400029; Wed, 6 May 2026 13:07:26 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Wed, 06 May 2026 13:07:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=queasysnail.net; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1778087246; x= 1778173646; bh=pg5UDl7ri/CJrMBtix6PRVI3CPKEaNW8yniAN0viWx4=; b=s F2AKF7YRms/po+4IqdiEQUfov7zBJ05JY4R1AL6Jasnalh40ilnZq7AkvXEx7Zka eZcBZRZv4ITDEyLSIKb6eFgesVzSnpOEcPGkPgelHChNeazSCTQcDdDaW9cCwQ2g 7imii/68OVmomZlRyG6/UZpHu6VlTpTAqx1kF7K2riFhyCwl5yI+ENgc4AEk7SqG BCKgwyGTUDK1JOgNElXnga1MTAoLZIYysz2LfxQqpNeU9m1iyiq/9HXwbsMyhSSa gz3SmlIgw0cRUF9iVXsnjoyuHUfMkXfxreE1HqPORaMnSzT7ZXWwMVGDxojIkTPj m0EjIrIjYaVXDc4h8sPzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1778087246; x=1778173646; bh=pg5UDl7ri/CJrMBtix6PRVI3CPKEaNW8yni AN0viWx4=; b=rrf7ZRyY3ukr1rq26NZhmTR9K/oi3w7H5uC36pIGVU2Ndsy7Dpr RML+TE+jp8VoZQ+NzxUOPnFzWzXyw4ODUG1chzKugYAvmXWmVzxm84iJgI1PmXUQ D5l6xEWywvxOddxj2ke+o1Sg9mUygFg0dUXtmMt9Q/FOT6xtHD0i8nOGwkljiYhI ek0OMhAIFLI4yAEyzVpFqkBqwWFWsyK4andXwSgUtQmQOiw1liqvL4qIzKQBiK0m 5z9c9eLkJXgXzc320xnz5a0ap+8z/S+wapn2KbVKknLVO7lL26IslzBxkSGtjFjK t4lw1u1j9sFMR7M9gYBBVzjk+1b4lyNQwHw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddutdehudehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtjeenucfhrhhomhepufgrsghrihhn rgcuffhusghrohgtrgcuoehsugesqhhuvggrshihshhnrghilhdrnhgvtheqnecuggftrf grthhtvghrnhepuefhhfffgfffhfefueeiudegtdefhfekgeetheegheeifffguedvueff fefgudffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshgusehquhgvrghshihsnhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeduvddpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtoheprhhjvghthhifrghnihesphhurhgvshhtoh hrrghgvgdrtghomhdprhgtphhtthhopehnvghtuggvvhesvhhgvghrrdhkvghrnhgvlhdr ohhrghdprhgtphhtthhopehsrggvvggumhesnhhvihguihgrrdgtohhmpdhrtghpthhtoh epthgrrhhiqhhtsehnvhhiughirgdrtghomhdprhgtphhtthhopehmsghlohgthhesnhhv ihguihgrrdgtohhmpdhrtghpthhtohepsghorhhishhpsehnvhhiughirgdrtghomhdprh gtphhtthhopehjohhhnhdrfhgrshhtrggsvghnugesghhmrghilhdrtghomhdprhgtphht thhopehkuhgsrgeskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepuggrvhgvmhesuggrvh gvmhhlohhfthdrnhgvth X-ME-Proxy: Feedback-ID: i934648bf:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 6 May 2026 13:07:25 -0400 (EDT) Date: Wed, 6 May 2026 19:07:23 +0200 From: Sabrina Dubroca To: Rishikesh Jethwani Cc: netdev@vger.kernel.org, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, borisp@nvidia.com, john.fastabend@gmail.com, kuba@kernel.org, davem@davemloft.net, pabeni@redhat.com, edumazet@google.com, leon@kernel.org Subject: Re: [PATCH v13 6/6] selftests: net: add TLS hardware offload test Message-ID: References: <20260429181016.3164935-1-rjethwani@purestorage.com> <20260429181016.3164935-7-rjethwani@purestorage.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260429181016.3164935-7-rjethwani@purestorage.com> 2026-04-29, 12:10:16 -0600, Rishikesh Jethwani wrote: [...] > +static int do_client(void) > +{ Both this and do_server could be refactored into a few nice helpers (prep the socket up to connect+ulp/accept+ulp, echo handling, rekey, payload verification on RX). [...] > + for (i = 1; i <= num_iterations; i++) { > + int this_size; > + > + if (random_size_max > 0) > + this_size = (rand() % random_size_max) + 1; > + else > + this_size = send_size; > + > + /* In burst mode, use a per-iteration fill pattern so the > + * receiver can detect any plaintext corruption without a > + * round-trip echo. > + */ > + if (burst_mode) { > + memset(buf, i & 0xFF, this_size); > + } else { > + for (j = 0; j < this_size; j++) > + buf[j] = rand() & 0xFF; > + } > + > + n = send(csk, buf, this_size, 0); > + if (n != this_size) { > + printf("FAIL: send failed: %s\n", strerror(errno)); > + goto out; > + } > + /* Throttle per-iteration progress lines on long burst runs so > + * stdout over ssh doesn't become the bottleneck. I'm not sure those lines have enough benefit in burst mode to be worth printing. (same on the server side) > +static int do_server(void) > +{ [...] > + while (1) { [...] > + /* Burst mode: verify payload matches the client's fill > + * pattern. TLS record boundaries may differ from send() > + * boundaries, so walk the received buffer in chunks that > + * fit within the current iteration's remaining bytes. > + * Catches decrypt-succeeded-but-plaintext-corrupt bugs > + * that AEAD counters alone would miss. > + */ > + if (burst_mode) { > + int off = 0; > + > + while (off < n) { This would be a good deal simpler if you passed MSG_WAITALL to the recvmsg call in burst mode. Then you'd get the full chunk of data for that iteration. [...] > +static void print_usage(const char *prog) > +{ > + printf("TLS Hardware Offload Two-Node Test\n\n"); > + printf("Usage:\n"); > + printf(" %s server [OPTIONS]\n", prog); > + printf(" %s client -s [OPTIONS]\n", prog); > + printf("\nOptions:\n"); > + printf(" -s Server IPv4 address (client, required)\n"); > + printf(" -p Server port (default: 4433)\n"); > + printf(" -b Send buffer size in bytes (default: 16384)\n"); > + printf(" -r Use random send buffer sizes (1..)\n"); > + printf(" -v TLS version: 1.2 or 1.3 (default: 1.3)\n"); > + printf(" -c Cipher: 128 or 256 (default: 128)\n"); > + printf(" -n Number of send/echo iterations (default: 100)\n"); > + printf(" -k Perform N rekeys (client only, TLS 1.3; N < iterations)\n"); > + printf(" -B Burst mode: client sends continuously without echo;\n"); > + printf(" server drains and handles KeyUpdate without responding.\n"); > + printf(" -Z Enable zero-copy RX (TLS_RX_EXPECT_NO_PAD);\n"); This is misleading, since zero-copy RX will be enabled by default for 1.2. > diff --git a/tools/testing/selftests/drivers/net/hw/tls_hw_offload.py b/tools/testing/selftests/drivers/net/hw/tls_hw_offload.py > new file mode 100755 > index 000000000000..f12da0e66afd > --- /dev/null > +++ b/tools/testing/selftests/drivers/net/hw/tls_hw_offload.py [...] > +def verify_tls_counters(stats_before, stats_after, expected_rekeys, > + tls_role, is_dut, burst=False): > + """Verify TLS counters on one side of the connection. Even with the introduction of the check_* helpers, this function still has a lot of c/p'd code just depending on role and test mode. > + tls_role: 'client' or 'server' (TLS role this side played). > + is_dut: True for the local DUT; requires HW offload counters. > + burst: burst mode - only the TLS client rotates its TX key; the TLS > + server only follows with an RX rotation on KeyUpdate receipt. > + """ > + errors = 0 > + role = 'DUT' if is_dut else 'Peer' > + > + # In burst mode only one direction carries TLS traffic per side > + # (TLS client sends, TLS server receives). Check HW offload only on > + # the active direction(s); require HW on the DUT's active direction. > + if burst: > + if tls_role == 'client': > + errors += check_path(stats_before, stats_after, 'Tx', role, > + require_hw=is_dut) > + else: > + errors += check_path(stats_before, stats_after, 'Rx', role, > + require_hw=is_dut) > + else: > + errors += check_path(stats_before, stats_after, 'Tx', role, > + require_hw=is_dut) > + errors += check_path(stats_before, stats_after, 'Rx', role, > + require_hw=is_dut) # in burst mode, client does TX and server only does RX # otherwise, both sides do both TX and RX with_tx = not burst or tls_role == 'client': with_rx = not burst or tls_role != 'client': if with_tx: check_path(Tx...) if with_rx: check_path(Rx...) > + if expected_rekeys > 0: > + if burst: > + if tls_role == 'client': > + errors += check_min(stats_before, stats_after, > + 'TlsTxRekeyOk', expected_rekeys, role) > + errors += check_zero(stats_before, stats_after, > + 'TlsTxRekeyError', role) and same for those > + else: > + errors += check_min(stats_before, stats_after, > + 'TlsRxRekeyOk', expected_rekeys, role) > + errors += check_min(stats_before, stats_after, > + 'TlsRxRekeyReceived', expected_rekeys, > + role) > + errors += check_zero(stats_before, stats_after, > + 'TlsRxRekeyError', role) > + else: > + errors += check_min(stats_before, stats_after, > + 'TlsTxRekeyOk', expected_rekeys, role) > + errors += check_min(stats_before, stats_after, > + 'TlsRxRekeyOk', expected_rekeys, role) > + if tls_role == 'server': > + errors += check_min(stats_before, stats_after, > + 'TlsRxRekeyReceived', expected_rekeys, > + role) Why are you restricting this to the server? The client should get as many rekeys as it sends. > + errors += check_zero(stats_before, stats_after, > + 'TlsTxRekeyError', role) > + errors += check_zero(stats_before, stats_after, > + 'TlsRxRekeyError', role) > + > + errors += check_zero(stats_before, stats_after, 'TlsDecryptError', role) > + > + return errors == 0 -- Sabrina