sockopt: uniform code to get/set values #353
Comments
|
Suggestion: probably most cases can be handled with such generic function: static int mptcp_setsockopt_all_sf(struct mptcp_sock *msk, int level,
int optname, sockptr_t optval,
unsigned int optlen,
int (*get_val)(struct sock *),
void (*set_val)(struct sock *, int))
{
struct mptcp_subflow_context *subflow;
struct sock *sk = (struct sock *)msk;
int err, val;
err = tcp_setsockopt(sk, level, optname, optval, optlen);
if (err != 0)
return err;
lock_sock(sk);
sockopt_seq_inc(msk);
val = get_val(sk);
mptcp_for_each_subflow(msk, subflow) {
struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
bool slow = lock_sock_fast(ssk); /* Not needed? */
set_val(ssk, val);
unlock_sock_fast(ssk, slow);
}
release_sock(sk);
return 0;
}Example: static int get_ip_treansparent(struct sock *sk)
{
return inet_sk(sk)->transparent;
}
static int set_ip_treansparent(struct sock *sk, int val)
{
return inet_sk(sk)->transparent;
}
(...)
switch (optname) {
case IP_TRANSPARENT:
return mptcp_setsockopt_all_sf(msk, level, optname, optval, optlen,
&get_ip_treansparent, &set_ip_treansparent);(and add WDYT? |
|
Hey, I hit some issue with setsockopt() with IP_TRANSPARENT (IPv4) when using MPTCPv1 (kernel version 5.15.0-69). It seems that IP_TRANSPARENT is not supported in 5.15.0-69. Should I upgrade my kernel ? do you have any recommendation on which version I should use ? Thanks. |
|
Hi @funglee2k22, You need at least the v5.17: https://github.com/multipath-tcp/mptcp_net-next/wiki#changelog
MPTCPv1 is the protocol version, not the implementation. https://github.com/multipath-tcp/mptcp_net-next/wiki#mptcpv0-vs-mptcpv1 |
|
@matttbe Thanks Matt, I upgrade to 6.1.23. and IP_TRANSPARENT starts working. Thanks. Currently, I have some issues with a dual haproxy setup. Before I move to haproxy I had the shadowsock-libev solution working w/ mptcpv1. The similar setup (dual haproxy setup) was working fine with the mptcpv0.97 (4.* kernel). But now, not matter what I did, I could not get the dual-haproxy working (subflow is not added). (Note, both haproxy are running as a transparent proxy.). Is there any recommendation how to debug this issue ? |
|
@funglee2k22 I think it would be better if you open a new issue about that, that's not related to the factoring suggested here. In the description of this new issue, please explain how you forced HAProxy to use MPTCP (with mptcpize?) + share output of |
Currently, to get socket option, we deal with them case by case by looking at the field that has been set and copying what is done elsewhere in SOL_IP(V6). That's probably why there is only one being supported here with IP_TOS. Instead, we can use ip(v6)_getsockopt() to retrieve the value. By doing that, we can also go through the BPF et Netlink hooks if needed and we can easily support new options later. While at it, also fix the variable declaration order to respect the reverse xmas tree convention. Link: multipath-tcp#353 Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Currently, to set socket option, we mostly deal with them case by case by setting the right field in the socket structure and in fact, copying what is done elsewhere in SOL_IP(V6). Supporting a new option is then more complex and we can see some disparities on how things are done between the different options. Instead, we can rely on ip(v6)_setsockopt() to set the different values. By doing that, we uniform the way we deal with the different options and we can also go through the BPF et Netlink hooks if needed. We can also easily support new options later. Note that there are still two cases where we still need to deal with the end values directly, thus with something specific case by case: - For SOL_TCP socket options because we cannot store them in the MPTCP socket. Note we can also store info in the different subflows (and create a first one if there is no subflow) and retrieve info from there. - To sync the socket options when a new subflow has been created to minimise the work. But maybe it is fine to call some getsockopt() / setsockopt(). We could also save a list of setsockopt() that have been done in the past and only re-do these ones. That should help with the maintenance of these socket options and ease the support of new ones. Link: multipath-tcp#353 Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Currently, to get socket option, we deal with them case by case by looking at the field that has been set and copying what is done elsewhere in SOL_IP(V6). That's probably why there is only one being supported here with IP_TOS. Instead, we can use ip(v6)_getsockopt() to retrieve the value. By doing that, we can also go through the BPF et Netlink hooks if needed and we can easily support new options later. While at it, also fix the variable declaration order to respect the reverse xmas tree convention. Link: multipath-tcp#353 Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Currently, to set socket option, we mostly deal with them case by case by setting the right field in the socket structure and in fact, copying what is done elsewhere in SOL_IP(V6). Supporting a new option is then more complex and we can see some disparities on how things are done between the different options. Instead, we can rely on ip(v6)_setsockopt() to set the different values. By doing that, we uniform the way we deal with the different options and we can also go through the BPF et Netlink hooks if needed. We can also easily support new options later. Link: multipath-tcp#353 Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Currently, to set socket option, we mostly deal with them case by case by setting the right field in the socket structure and in fact, copying what is done elsewhere in SOL_IP(V6). Supporting a new option is then more complex and we can see some disparities on how things are done between the different options. Instead, we can rely on ip(v6)_setsockopt() to set the different values. By doing that, we uniform the way we deal with the different options and we can also go through the BPF et Netlink hooks if needed. We can also easily support new options later. Link: multipath-tcp#353 Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
When looking at
net/mptcp/sockopt.ccode, I can see multiple ways to set and get values. For example, for thesetsockopt()side, we have:IP_TRANSPARENT:ip_setsockopt()is called on the MPTCP socksync_socket_options()will set the same value to all the new subflows created afterIPV6_TRANSPARENT: the oppositetcp_setsockopt()is called on the first subflowsync_socket_options()IP_TOS: similar toIP_TRANSPARENTbut on all subflowsip_setsockopt()is called on the MPTCP socksync_socket_options()TCP_FASTOPEN:tcp_setsockopt()is called on the first subflowTCP_INQ:tcp_setsockopt()is not used but we do the sameSO_TIMESTAMPNS:sock_setsockopt()is usedetc.
The text was updated successfully, but these errors were encountered: