flags: add 'laminar' endpoints support #326
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Test Coverage Report for Build 19644256155Details
💛 - Coveralls |
matttbe
force-pushed
the
pm-kern-endp-add_addr-new
branch
from
c7dc293 to
fc6e388
Compare
matttbe
commented
Oct 15, 2025
| # | ||
| # See the ip-mptcp(8) man page for details. | ||
| # | ||
| # addr-flags=subflow |
Member
Author
There was a problem hiding this comment.
I wonder if we should not set subflow,laminar by default. Older kernel versions will accept that.
Member
Author
There was a problem hiding this comment.
I wonder if we should not set
subflow,laminarby default. Older kernel versions will accept that.
(if yes, I'm not so sure how to "cleanly" change the default value :) )
mjmartineau
changed the title
matttbe
commented
Nov 14, 2025
Member
Author
matttbe
left a comment
matttbe
left a comment
There was a problem hiding this comment.
@ossama-othman thank you for the reviews!
ossama-othman
approved these changes
Nov 24, 2025
Some new defines related to MPTCP_INFO and EV flags, and switch to _BITUL(). Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
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]>
Endpoints are usually added with a flag: validate that. Set a random one (the new 'subflow' one) instead of 0. Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
This parameter was not validated before. Use all possible flags (even if they are not individually checked). Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
force-pushed
the
pm-kern-endp-add_addr-new
branch
from
4a58168 to
68c2614
Compare
Member
Author
|
Thank you for the review! I had to rebase (conflicts in The CI is still happy, I suggest merging then! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, upon the reception of an
ADD_ADDR(and when thefullmeshflag 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:
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 byfullmesh.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