netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Tony Lu <tonylu@linux.alibaba.com>,
	ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: RE: [PATCH bpf-next 0/2] Introduce TCP_ULP option for bpf_{set,get}sockopt
Date: Thu, 09 Dec 2021 11:27:41 -0800	[thread overview]
Message-ID: <61b258ad273a9_6bfb2084d@john.notmuch> (raw)
In-Reply-To: <20211209090250.73927-1-tonylu@linux.alibaba.com>

Tony Lu wrote:
> This patch set introduces a new option TCP_ULP for bpf_{set,get}sockopt
> helper. The bpf prog can set and get TCP_ULP sock option on demand.
> 
> With this, the bpf prog can set TCP_ULP based on strategies when socket
> create or other's socket hook point. For example, the bpf prog can
> control which socket should use tls or smc (WIP) ULP modules without
> modifying the applications.
> 
> Patch 1 replaces if statement with switch to make it easy to extend.
> 
> Patch 2 introduces TCP_ULP sock option.

Can you be a bit more specific on what ULP you are going to load on
demand here and how that would work? For TLS I can't see how this will
work, please elaborate. Because the user space side (e.g. openssl) behaves
differently if running in kTLS vs uTLS modes I don't think you can
from kernel side just flip it on? I'm a bit intrigued though on what
might happen if we do did do this on an active socket, but seems it
wouldn't be normal TLS with handshake and keys at that point? I'm
not sure we need to block it from happening, but struggling to see
how its useful at the moment.

The smc case looks promising, but for that we need to get the order
correct and merge smc first and then this series.

Also this will need a selftests.

Thanks,
John

  parent reply	other threads:[~2021-12-09 19:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09  9:02 [PATCH bpf-next 0/2] Introduce TCP_ULP option for bpf_{set,get}sockopt Tony Lu
2021-12-09  9:02 ` [PATCH bpf-next 1/2] bpf: Use switch statement in _bpf_setsockopt Tony Lu
2021-12-09  9:02 ` [PATCH bpf-next 2/2] bpf: Introduce TCP_ULP option for bpf_{set,get}sockopt Tony Lu
2021-12-09 19:27 ` John Fastabend [this message]
2021-12-10  2:54   ` [PATCH bpf-next 0/2] " Tony Lu

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=61b258ad273a9_6bfb2084d@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=tonylu@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).