Re: [PATCH v12 6/6] selftests: net: add TLS hardware offload test

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 8 Apr 2026 18:45:53 +0200 Sabrina Dubroca wrote:
> @Jakub [top-posting so you don't have to scroll through the rest of my
> comments to find some global questions about this patch]

:)

> tools/testing/selftests/drivers/net/README.rst mentions "Local
> host is the DUT", but this test does rekeys on both sides and sends a
> bit of traffic back and forth. Is that acceptable?

Yes, I think so. Quick scan thru the code doesn't real much about
configuration and how the test ensure HW offload is engaged.
But sending traffic is the intended use of the remote host.

The statement is basically saying that if we have 2 hosts the local
one is going to have the kernel to test installed. The remote host
may have old kernel and no offloads available, it's just a traffic
source/sink.

> Another thought: is there a "standard" for stdout vs stderr, as well as
> verbosity of "test progress"/"debug" type messages ("sent
> keyupdate"/"received keyupdate"/"server listening"/"setup complete"
> etc) for those test programs? Any expectation for a --{debug,verbose}
> option to only display all this stuff on request?
> 
> Output for 1 test:
> -------- 8< --------
> TLS Version: TLS 1.3
> Cipher: AES-GCM-128
> Buffer size: 16384
> Connecting to 192.168.13.1:4433...
> Connected!
> Installing TLS_TX AES-GCM-128 gen 0...
> TLS_TX AES-GCM-128 gen 0 installed
> Installing TLS_RX AES-GCM-128 gen 0...
> TLS_RX AES-GCM-128 gen 0 installed
> TLS setup complete.
> Sending 100 messages of 16384 bytes...
> Sent 16384 bytes (iteration 1)
> Received echo 16384 bytes (ok)
> [...repeated]
> Sent 16384 bytes (iteration 100)
> Received echo 16384 bytes (ok)
> -------- 8< --------
> 
> With some rekeys I get 300L of output on each side.
> 
> 
> If not, I guess we can fall back to what makes the most sense for
> NIPA?

Best practices for these "Python-wrapped" tests are.. evolving.
The current thinking is to avoid the prints in the good case,
unless there's actually something sketchy that we may want
to double check (eg. the test is triggering some condition
probabilistically and we want to see if / how many times it managed 
to trigger it)

IIRC the command failed exceptions already print the command + stdout +
stderr. So having the C binary always print the debug output and exit(1)
if something goes wrong is probably the way to go. Python should then
simply do cmd(..), if the command succeeds there's no output.
If the cmd() raises an exception we'll see the "debug" info.

bkg() should hopefully behave the same, with the caveat that bkg()
with no exit param (exit_wait, ksft_wait) should be avoided, cause
without those we have to kill the process which makes the exit checking
unreliable. I tried to make it a little better in commit d99aa5912
so its not the end of the world if wait can be used. But good tests
should be designed to wait.