Skip to content

Commit 3559ede

Browse files
committed
flags: add 'luminar' endpoints support
Currently, upon the reception of an ADD_ADDR (and when the fullmesh flag is not used), the in-kernel PM will create new subflows using the local address the routing configuration will pick. It would be easier to pick local addresses from a selected list of endpoints, and use it only once, than relying on routing rules. Use case: both the client (C) and the server (S) have two addresses (a and b). The client establishes the connection between C(a) and S(a). Once established, the server announces its additional address S(b). Once received, the client connects to it using its second address C(b). Compared to a situation without the 'laminar' endpoint for C(b), the client didn't use this address C(b) to establish a subflow to the server's primary address S(a). So at the end, we have: C S C(a) --- S(a) C(b) --- S(b) In case of a 3rd address on each side (C(c) and S(c)), upon the reception of an ADD_ADDR with S(c), the client should not pick C(b) because it has already been used. C(c) should then be used. Note that this situation is currently possible if C doesn't add any endpoint, but configure the routing in order to pick C(b) for the route to S(b), and pick C(c) for the route to S(c). That doesn't sound very practical because it means knowing in advance the IP addresses that will be used and announced by the server. 'laminar', like the idea of laminar flows: the different subflows don't mix with each other on an endpoint, unlike the "turbulent" way traffic is mixed by 'fullmesh'. This new flag is then added to mptcpd as well. Link: multipath-tcp/mptcp_net-next#503 Link: https://git.kernel.org/netdev/net-next/c/539f6b9de39e Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
1 parent 4802521 commit 3559ede

File tree

7 files changed

+14
-4
lines changed

7 files changed

+14
-4
lines changed

etc/mptcpd.conf.in

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,7 @@ path-manager=@mptcpd_default_pm@
3737
# signal (do not use with the "fullmesh" flag)
3838
# backup
3939
# fullmesh (do not use with the "signal" flag)
40+
# laminar
4041
#
4142
# Plugins that deal with the in-kernel path manager may use these
4243
# flags when advertising addresses.

include/linux/mptcp_upstream.h

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,7 @@
3939
#define MPTCP_PM_ADDR_FLAG_BACKUP _BITUL(2)
4040
#define MPTCP_PM_ADDR_FLAG_FULLMESH _BITUL(3)
4141
#define MPTCP_PM_ADDR_FLAG_IMPLICIT _BITUL(4)
42+
#define MPTCP_PM_ADDR_FLAG_LAMINAR _BITUL(5)
4243

4344
struct mptcp_info {
4445
__u8 mptcpi_subflows;
@@ -68,7 +69,8 @@ struct mptcp_info {
6869
__u64 mptcpi_bytes_received;
6970
__u64 mptcpi_bytes_acked;
7071
__u8 mptcpi_subflows_total;
71-
__u8 reserved[3];
72+
__u8 mptcpi_endp_laminar_max;
73+
__u8 reserved[2];
7274
__u32 mptcpi_last_data_sent;
7375
__u32 mptcpi_last_data_recv;
7476
__u32 mptcpi_last_ack_recv;

include/mptcpd/types.h

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -73,6 +73,9 @@ typedef uint32_t mptcpd_flags_t;
7373
* @note Do not use with @c MPTCPD_ADDR_FLAG_SIGNAL.
7474
*/
7575
#define MPTCPD_ADDR_FLAG_FULLMESH (1U << 3)
76+
77+
/// Use this endpoint in reaction to ADD_ADDR, but only once.
78+
#define MPTCPD_ADDR_FLAG_LAMINAR (1U << 5)
7679
///@}
7780

7881
/**

man/mptcpd.8.in

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -72,8 +72,9 @@ is a comma separated list containing one or more of the flags
7272
.IR subflow ,
7373
.IR signal ,
7474
.IR backup ,
75+
.IR fullmesh ,
7576
and
76-
.I fullmesh
77+
.IR laminar
7778
that plugins that deal with the in-kernel path manager may use when
7879
advertising addresses, e.g.
7980
.B --addr-flags=subflow

plugins/path_managers/addr_adv.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -54,7 +54,8 @@ static void update_limits(struct mptcpd_pm *pm, int delta)
5454
If the pm creates outgoing subflows, we assume this is
5555
the client side, and accepts add_addrs from the server.
5656
*/
57-
if (pm->config->addr_flags & MPTCPD_ADDR_FLAG_SUBFLOW)
57+
if (pm->config->addr_flags &
58+
(MPTCPD_ADDR_FLAG_SUBFLOW | MPTCPD_ADDR_FLAG_LAMINAR))
5859
_limits[1].limit = _limits[0].limit;
5960

6061
int const result = mptcpd_kpm_set_limits(pm,

src/configuration.c

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -121,6 +121,7 @@ static struct tok_entry const addr_flags_toks[] = {
121121
{ MPTCPD_ADDR_FLAG_SIGNAL, "signal" },
122122
{ MPTCPD_ADDR_FLAG_BACKUP, "backup" },
123123
{ MPTCPD_ADDR_FLAG_FULLMESH, "fullmesh" },
124+
{ MPTCPD_ADDR_FLAG_LAMINAR, "laminar" },
124125
{ 0, NULL },
125126
};
126127

src/netlink_pm_upstream.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,8 @@
3434
#if MPTCPD_ADDR_FLAG_SIGNAL != MPTCP_PM_ADDR_FLAG_SIGNAL \
3535
|| MPTCPD_ADDR_FLAG_SUBFLOW != MPTCP_PM_ADDR_FLAG_SUBFLOW \
3636
|| MPTCPD_ADDR_FLAG_BACKUP != MPTCP_PM_ADDR_FLAG_BACKUP \
37-
|| MPTCPD_ADDR_FLAG_FULLMESH != MPTCP_PM_ADDR_FLAG_FULLMESH
37+
|| MPTCPD_ADDR_FLAG_FULLMESH != MPTCP_PM_ADDR_FLAG_FULLMESH \
38+
|| MPTCPD_ADDR_FLAG_LAMINAR != MPTCP_PM_ADDR_FLAG_LAMINAR
3839
# error Mismatch between mptcpd and upstream kernel addr flags.
3940
#endif
4041

0 commit comments

Comments
 (0)