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/bba00a6cde75bab5a2c1c196d49812b4ed6addb0
Thanks,
-Geliang
