multipath-tcp / mptcpd / 19644312326
67%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 17
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 67.044% (-1.6%) from 68.597%
19644312326

push

github

web-flow 
flags: add 'laminar' endpoints support (#326)

* include: update MPTCP upstream headers

Some new defines related to MPTCP_INFO and EV flags, and switch to
_BITUL().

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

* 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: https://github.com/multipath-tcp/mptcp_net-next/issues/503
Link: https://git.kernel.org/netdev/net-next/c/539f6b9de39e
Signed-off-by: Matth... (continued)

1481 of 2209 relevant lines covered (67.04%)

18.06 hits per line

Uncovered Existing Lines

Lines Coverage ∆ File
8
29.25
 -2.23% src/path_manager.c
49
73.94
 -13.92% src/netlink_pm_upstream.c
Jobs
ID Job ID Ran Files Coverage
1 19644312326.1 34
65.89
 GitHub Action Run
Source Files on build 19644312326