All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Maxim Mikityanskiy <maximmi@nvidia.com>
Cc: dsahern@gmail.com, netdev@vger.kernel.org,
	stephen@networkplumber.org, tariqt@nvidia.com
Subject: Re: [PATCH iproute2-next v2] ss: Shorter display format for TLS zerocopy sendfile
Date: Tue, 7 Jun 2022 10:30:28 -0700	[thread overview]
Message-ID: <20220607103028.15f70be6@kernel.org> (raw)
In-Reply-To: <21b34b86-d43b-e86a-57ec-0689a9931824@nvidia.com>

On Tue, 7 Jun 2022 13:35:19 +0300 Maxim Mikityanskiy wrote:
> > 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.  
> 
> We can even make it as short as zc_ro_tx in that case.

SG

> Regarding sendmsg, I can't anticipate what knob will be used. There is 
> MSG_ZEROCOPY which is also a candidate.

Right, that's what I'm wondering. MSG_ZEROCOPY already has some
restrictions on user not touching the data but technically a pure 
TCP connection will not be broken if the data is modified. I'd lean
towards requiring the user setting zc_ro_tx, but admittedly I don't
have a very strong reason.

> Note that the constant in the header file has "SENDFILE" in its name, so 
> if you want to reuse it for the future sendmsg zerocopy, we should think 
> about renaming it in advance, before anyone starts using it. 
> Alternatively, an alias for this constant can be added in the future.

Would be good to rename it to whatever we settle for on the iproute2
side. Are we going with zc_ro_tx, then?

  reply	other threads:[~2022-06-07 17:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01 12:23 [PATCH iproute2-next] ss: Shorter display format for TLS zerocopy sendfile Maxim Mikityanskiy
2022-06-01 23:42 ` [PATCH iproute2-next v2] " Jakub Kicinski
2022-06-02  9:13   ` Maxim Mikityanskiy
2022-06-02 16:44     ` Jakub Kicinski
2022-06-03 13:47       ` Maxim Mikityanskiy
2022-06-03 15:51         ` Jakub Kicinski
2022-06-06 11:29           ` Maxim Mikityanskiy
2022-06-06 15:45             ` Stephen Hemminger
2022-06-06 17:59             ` Jakub Kicinski
2022-06-07 10:35               ` Maxim Mikityanskiy
2022-06-07 17:30                 ` Jakub Kicinski [this message]
2022-06-07 21:08                   ` Stephen Hemminger
2022-06-08 10:04                   ` Maxim Mikityanskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220607103028.15f70be6@kernel.org \
    --to=kuba@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=maximmi@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=tariqt@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.