We just had our 52nd meeting with Mat and Ossama (Intel OTC), Christoph
(Apple), Paolo, Davide and Florian (Red Hat) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
- net: mptcp: don't leak 'slab' and 'slab_name' on exit:
- by Davide
- accepted by Mat
- squashed in "mptcp: Create SUBFLOW socket for incoming
- Typo in mptcp_connect.sh:
- by Florian
- accepted by Matth
- squashed in "mptcp: selftests: switch to netns+veth based tests"
- mptcp: switch sublist to mptcp socket lock protection:
- by Florian
- v4 accepted by Mat
- added at the end
- mptcp: Make mptcp initialization part of tcp initialization:
- by Peter
- v2 accepted by Florian
- squashed in 3 different commits
- small notifications done when applying the patch, see ML for
- RFC by Peter:
- he is working on a v2
(+ a rebase after last changes made by Florian)
- mptcp:init: panic in case of error:
- by Matthieu
Sync with net-next:
- no sync last night because of an error: net-next doesn't compile
when IPV6 not compiled:
./include/linux/netfilter_ipv6.h: In function 'nf_ipv6_br_defrag':
./include/linux/netfilter_ipv6.h:110:9: error: implicit
declaration of function 'nf_ct_frag6_gather'; did you mean
- fix v2: https://patchwork.ozlabs.org/patch/1108255/
- should we always compile with IPV6 support?
→ We can do that later when we will have MPTCP IPv6 support
How to handle sk_state on the mptcp socket:
- FastClose: better to take the option B: send reset and clear
resources, no need to have an extra state (WAIT_FOR_RST)
- when creating the new MPTCP connection, we maintain our own state
(using TCP state)
- after, we are linked to the data connection → MPTCP connection.
→ if one sf established and one connecting, we are still in
→ we can be in a situation where there is no more subflow:
→ until we get a DATA_FIN
→ for a first version, we can also stop the MPTCP connection if
there is no more subflows if it is easier in the code
→ we can have a timeout when there is no more subflow (and no
→ Mat will add note in the wiki
→ we will need to support that, can be done later:
- do we need to support it now?:
→ Not for a first step
- if no, what to do?:
- we should not break TFO without MPTCP
- ignore TFO with MPTCP for the moment
- be sure that TFO doesn't break MPTCP! (that was the comment
from Paolo on Peter's RFC)
- add some comments (TODO) if we are thinking we would need an
adaptation in the future (not to forget them)
- (on the ML) Mat: At an earlier point we thought there would be a
need to read the list without holding a lock, but I don't remember what
that case was and looking at the current code the socket lock works well.
- (on the ML) Christoph: I think, that was to support lockless
subflow establishment, similar to the way Linux supports lockless
(meaning, without taking the listener's lock) connection establishment
on the server-side.
- we need to take the lock when we want to add stuff to the list. To
support lock-less establishment, we don't want to take MPTCP lock on the
server side. To avoid taking the lock when anything want to walk through
to list of sf, we need an RCU list. (racing against a 3rd ACK that
confirms the SF establishment). We would only need to access the list
lock when we modify the list, not when we walk through the RCU list.
- Paolo: RCU adds latency overhead, especially when there are
syscalls (sync needed)
- difficult to know the cost of the contention we would have with a
lock instead of RCU.
- we don't have to support the lock-less establishment but TCP was
going on this direction (lock-less)
- when Christoph did that in mptcp.org
, he saw a great improvement
with Apache benchmark.
- we can also improve this later: best design first and
- currently some syscall can modify shared stuff: if run in //, they
could create memleaks or deref pointers:
- Paolo has a patch to fix some problems there
- the idea would be sent them as RFC and postpone their
application for after MP_JOIN support
- no being able to walk through the list can be an issue for the
stats, e.g.: if we want to list the MPTCP and show the number of
subflows, we would like to avoid taking locks there
- warnings: "Replaced mapping before it was done"
- some were fixed by a fix from Paolo.
- reproducible using:
- running on a single CPU
- but tests are successful
- with and without KASAN and PROVE_LOCKING config.
- now testing KSelftests
- scripts are available in the 'scripts' branch
- Suggestions for the future:
- by Mat: enable debug features like CONFIG_KASAN and
CONFIG_PROVE_LOCKING in the test kernel and then check the console
output for KASAN/locking issues. There is a tradeoff in speed, but it
could alert us to problems the selftests alone don't catch.
- done → now always running with them
- But might be interesting to run without and with ↑
- TODO: Matth can update the scripts (feel free to propose
changes for these scripts too!)
- will be next year in March in Canada (west coast, Vancouver)
- nothing new
- We propose to have it next Thursday, the 6th of June.
- Christoph will not be able to join.
- Usual time: 16:00 UTC (9am PDT, 6pm CEST)
- Still open to everyone!
Feel free to comment on these points and propose new ones for the next
Talk to you next week,
Matthieu Baerts | R&D Engineer
Tessares SA | Hybrid Access Solutions
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium