| Message ID | 20211209090250.73927-1-tonylu@linux.alibaba.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce TCP_ULP option for bpf_{set,get}sockopt | expand |
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
On Thu, Dec 09, 2021 at 11:27:41AM -0800, John Fastabend wrote: > 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. Yep, we are developing a set of patch to do with smc for transparent replacement. The smc provides the ability to be compatible with TCP, the applications can be replaced with smc without no side effects. In most cases, it is impossible to modify the compiled application binary or inject into applications' containers with LD_PRELOAD. So we are using smc ULP to replace TCP with smc when socket create. These patches will be sent out soon. I will send them after smc's patches. Thank you. > > Also this will need a selftests. I will fix it. > > Thanks, > John Thanks, Tony Lu
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. Tony Lu (2): bpf: Use switch statement in _bpf_setsockopt bpf: Introduce TCP_ULP option for bpf_{set,get}sockopt include/uapi/linux/bpf.h | 3 +- net/core/filter.c | 180 ++++++++++++++++++--------------- tools/include/uapi/linux/bpf.h | 3 +- 3 files changed, 104 insertions(+), 82 deletions(-)