Hey Chuck,

On Tue, 2025-07-29 at 09:37 -0400, Chuck Lever wrote:

Hi Wilfred -

On 7/28/25 10:41 PM, Wilfred Mallawa wrote:

quoted

From: Wilfred Mallawa <redacted>

During a tls handshake, an endpoint may specify a maximum record
size limit. As
specified by [1]. which allows peers to negotiate a maximum
plaintext record
size during the TLS handshake. If a TLS endpoint receives a record
larger
than its advertised limit, it must send a fatal "record_overflow"
alert [1].
Currently, this limit is not visble to the kernel, particularly in
the case
where userspace handles the handshake (tlshd/gnutls).

This paragraph essentially says "The spec says we can, so I'm
implementing it". Generally we don't implement spec features just
because they are there.

What we reviewers need instead is a problem statement. What is not
working for you, and why is this the best way to solve it?

Thanks for the feedback.

Essentially, this is to support upcoming WD NVMe-TCP controller that
implements TLS support. These devices require record size negotiation
as they support a maximum record size less than the current kernel
default. I will add this to my V2 series in more detail.

quoted

This series in conjunction with the respective userspace changes
for tlshd [2]
and gnutls [3], adds support for the kernel the receive the
negotiated record
size limit through the existing netlink communication layer, and
use this
value to limit outgoing records to the size specified.

As Hannes asked elsewhere, why is it up to the TLS consumer to be
aware of this limit? Given the description here, it sounds to me
like something that should be handled for all consumers by the TLS
layer.

Yeah great point, I didn't think it through too well. I will address
this in V2 and have the record size limit implemented in the TLS layer
without involving ULPs.

Regards,
Wilfred