On Fri, May 31, 2024 at 01:13:39PM +0200, Jakub Sitnicki wrote:
On Thu, May 30, 2024 at 04:45 PM -07, John Fastabend wrote:
Geliang Tang wrote:
On Mon, 2024-05-27 at 21:36 +0200, Jakub Sitnicki wrote:
On Mon, May 27, 2024 at 10:12 AM -07, John Fastabend wrote:
Geliang Tang wrote:
[...]
The one advantage of test_sockmap is we can have it run for longer runs by pushing different options through so might be worth keeping just for that.
If you really want links here I'm OK with that I guess just asking.
It was me who suggested the switch to bpf_link in reaction to a series of cleanups to prog_type and prog_attach_type submitted by Geliang.
Yes, patches 3-5 address Jakub's suggestion: switching attachments to bpf_link.
OK. Lets just take them the series lgtm. Jakub any other comments?
Gave it a run - all looks well. Thanks for the patches.
Geliang, is there some MPTCP+sockmap use-case you're working towards?
Yes, indeed. I have been working on a task related to MPTCP+sockmap recently, at least related to this test_sockmap.c selftest. We recently received an issue with MPTCP [1], that is TLS cannot be set on MPTCP sockets. The reason is that both MPTCP and TLS are implemented on TCP ULP. And each socket only supports one type of TCP ULP.
I simply modified this test_sockmap.c selftest to support MPTCP, so that it can be used as the first version of test for MPTCP+TLS. So I spent some time reading and debugging this test.
The development of MPTCP+TLS is still ongoing, and currently only setsockopt part has been successfully supported. The idea is simple, use an array of tcp_ulp_ops in a socket, instead of a single one:
struct inet_connection_sock { ... ... const struct tcp_ulp_ops *icsk_ulp_ops[ULP_INDEX_MAX]; void __rcu *icsk_ulp_data[ULP_INDEX_MAX]; }
The entire patch is in my commit "mptcp: tls support" [2]. It's not finish yet, but I really want to hear your opinions, especially John's.
[1] https://github.com/multipath-tcp/mptcp_net-next/issues/480 [2] https://github.com/geliangtang/mptcp_net-next/commit/bba00a6cde75bab5a2c1c19...
Thanks, -Geliang