Re: [PATCH iproute2-next v2] ss: Shorter display format for TLS zerocopy sendfile

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 6 Jun 2022 14:29:02 +0300 Maxim Mikityanskiy wrote:
> > The difference is that the person writing the code (who will interact
> > with kernel defines) is likely to have a deeper understanding of the
> > technology and have read the doc. My concern is that an ss user will
> > have much more superficial understanding of the internals so we need
> > to be more careful to present the information in the most meaningful
> > way.
> > 
> > E.g. see the patch for changing dev->operstate to UP from UNKNOWN
> > because users are "confused". If you just call the thing "zc is enabled"
> > I'm afraid users will start reporting that the "go fast mode" is not
> > engaged as a bug, without appreciation for the possible side effects.  
> 
> That makes some sense to me. What about calling the ss flag 
> "zc_sendfile_ro" or "zc_ro_sendfile"? It will still be clear it's 
> zerocopy, but with some nuance.

That'd be an acceptable compromise. Hopefully sufficiently forewarned
users will mentally remove the zc_ part and still have a meaningful
amount of info about what the flag does.

Any reason why we wouldn't reuse the same knob for zc sendmsg()? If we
plan to reuse it we can s/sendfile/send/ to shorten the name, perhaps.

> > Dunno if it's useful but FWIW I pushed my WIP branch out:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/kuba/linux.git/commit/?h=tls-wip&id=d923f1049a1ae1c2bdc1d8f0081fd9f3a35d4155
> > https://git.kernel.org/pub/scm/linux/kernel/git/kuba/linux.git/commit/?h=tls-wip&id=b814ee782eef62d6e2602ab3ba7b31ca03cfe44c  
> 
> I took a glance, and I agree zerocopy isn't the best name for your 
> feature. If I wanted to indicate it saves one copy, I would call it 
> "direct decrypt". "Expect no pad" also works from the point of view of 
> declaring limitations.
> 
> Another topic to consider is whether TLS 1.3 should be part of the name, 
> and should "TlsDecryptRetry" be more specific (if a future feature also 
> retries decryption as a fallback, do we want to count these retries in 
> the same counter or in a new counter?)

I wanted to avoid the versions because TLS 1.4 may need the same
optimization.

You have a point about the more specific counter, let me add a counter
for NoPad being violated (tail == 0) as well as the overall "decryption
happened twice" counter.