[Weekly meetings] MoM - 31st of January 2019
by Matthieu Baerts
Hello,
We just had our 37th meeting with Mat and Ossama (Intel OTC), Christoph
(Apple), Hoang (UCLouvain) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Mat and Peter's new patch-set:
- it is on Gerrit:
https://review.gerrithub.io/c/multipath-tcp/mptcp_net-next/+/437388/6
- Matth and Christoph started the new reviews: see Gerrit
- Florian commented too:
https://lists.01.org/pipermail/mptcp/2019-January/000981.html
- Florian mentioned that it could be nice to add a kselftest. We
need to check how other network protocols are doing their kselftests.
(Florian also proposed to have a look at that.)
- ULP to manage subflows by Peter: seems to be the way to go not to
expose the new proto to userspace, linked to:
https://review.gerrithub.io/c/multipath-tcp/mptcp_net-next/+/437392/6
Integrate changes in MPTCP repo (mptcp_net-next):
- Proposition to integrate reviewed/validated (code review +2)
changes in mptcp net-next tree. It seems we are all OK with that.
- Matth can integrate changes directly in topgit (no need to use the
Gerrit' submit button)
- What would be upstreamed in term of code would be in t/upstream
branch but in term of commits (with the description) would be the result
of a 'tg export'.
- Matth: what is also possible is to ask the CI to 'tg export' on a
clean branch on top of Dave's net-next. It is something easy to do (with
1 topgit command). Might help people who doesn't want to setup topgit to
export the tree and see the commits messages.
Misc:
- alternative to topgit but for the future: git evolve
- doc:
https://github.com/gitster/git/blob/sx/evolve/Documentation/technical/evo...
- submission:
https://public-inbox.org/git/20190127194415.171035-1-sxenos@google.com/t/#u
What's next?
- we already discussed about that last time but without Peter and
Florian. We report this discussion to next week. Here are the questions
to discuss:
- focus on the first patch-set and try to upstream this base?
- integrate Mat and Peter's patch-set in our topgit tree? (or at
least what we agreed on) not to have a lot of pending changes?
- removing feature on mptcp_net-next/master?
- testing? (packetdrill?)
mptcp_trunk:
- two new patches from Christoph. To be reviewed and applied.
Next meeting:
- We propose to have the next one on Thursday, the 7th of February.
- Usual time: 17:00 UTC (9am PST, 6pm CET)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20190207
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
2 years, 8 months
Questions/remarks wrt. mptcp layered prototype
by Florian Westphal
Hi.
I had a look at the layered prototype, here are some questions/remarks.
1) mptcp_close():
hlist_del_rcu(node);
spin_unlock_bh(&msk->conn_list_lock);
synchronize_rcu();
pr_debug("conn_list->subflow=%p", subflow);
sock_release(sock_sk(subflow)->sk_socket);
} while (1);
What is this synchronize_rcu() supposed to protect/do?
AFAICS it can be removed?
2) struct tcp_options_received should really have IS_ENABLED(CONFIG_MPTCP)
wrap for the mptcp struct; unlike smc it increases struct size.
So better appease those that have CONFIG_MPTCP=n.
3) running scripts/checkpatch.pl spews out a gazillion of warnings,
I would suggest fix those up rather sooner than later.
Its annoting task for sure, but someone has to do it.
4) the networking maintainer enforces reverse-xmas tree for variable
declarations, so
if (tcp_rsk(req)->is_mptcp) {
u64 local_key;
u64 remote_key;
must become
if (tcp_rsk(req)->is_mptcp) {
u64 remote_key;
u64 local_key;
This might seems silly, but thats how things are.
5) The line in skbuff.c adding the mptcp extension should look like this
[SKB_EXT_MPTCP] = SKB_EXT_CHUNKSIZEOF(struct mptcp_skb_cb),
Also, mptcp_skb_cb still contains obsolete reference count.
(while at it, probably better to rename struct, mptcp_skb_cb makes
me think its stored in skb->cb[]).
6) I think it would help to add an mptcp kselftest; I can look at this next.
Thanks,
Florian
2 years, 8 months
[Weekly meetings] MoM - 24th of January 2019
by Matthieu Baerts
Hello,
We just had our 36th meeting with Mat and Ossama (Intel OTC), Christoph
(Apple), Hoang (UCLouvain) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Netlink PM:
- v8 has been merged!
- (no more subflow_error events → cf. last meeting)
- we will see what people will do with it!
- pretty close match with what Intel Netlink PM was supposed to be
- Ossama's userspace code will be shared soon:
- can share a first version which is not compatible with the
current kernel Netlink PM now in mptcp_trunk
- compatibility will come later
Idea of a BPF PM for servers:
- a simple PM, only to announce IP addresses given by the userspace
- BPF to write IP address
- that's the complex part, certainly to write this in PM private
memory
- then the idea would be to hook (kprobe?) and call a function to do
that?
- With BPF it means that you need to define a new API for actions
you can do (and maintain this API)
What's next?
- focus on the first patch-set and try to upstream this base?
Mat: is looking at the DATA-FIN (because the disconnect part is
not fully managed for the moment)
Peter: he is also looking at improving this (and MP+Join)
→ when this is done, we can start comparing that with
mptcp_net-next/master (with extra removal) ; accept the design ;
finalise patches and upstream this
- removing feature on mptcp_net-next/master?
Christoph has more removal in the queue (removal of the client
side + stats ; 2k lines are removed)
- testing? (packetdrill?)
Peter is also looking at that
Would need to check how this job can be shared
CI:
- Matth: update t/upstream manually this time, automatically later.
- Feel free to ask for an update of t/upstream while it is not done
automatically, it is really easy and quick
mptcp stable:
- not so many users of v0.93? (at least not so many downloads of the
RPM/DEB)
- will continue to maintain v0.94 for a while (EOL for v4.14 is
January 2020)
Next meeting:
- We propose to have the next one on Thursday, the 31st of January.
- Usual time: 17:00 UTC (9am PST, 6pm CET)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20190131
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
2 years, 9 months
[Weekly meetings] MoM - 17th of January 2019
by Matthieu Baerts
Hello,
We just had our 35th meeting with Mat, Peter and Ossama (Intel OTC),
Christoph (Apple) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Netdev:
- New interesting talk to follow: (by Florian)
https://www.netdevconf.org/0x13/session.html?skb-meta-data-extensions
GSOC:
- https://lwn.net/Articles/776816/rss
- hard to know what we can ask students to do now, we will need time
to "bootstrap" this student with unclear objectives (for the moment)
- maybe easier when we will have a base and a clear list of features
that need to be added (next year then?)
Gerrit:
- Gerrit now sends notifications when new changes are created (we
can also send notifications when there is a new version of a published
patch-set, for each comment, when it is merged, only for some branches,
etc. but people can also subscribe when they want to get all
notifications or configure their profile → or we could also setup an
extra ML just for that? There are other solutions for those who want
more notifications :) )
- if you want to use gerrithub, simply use:
- git review t/upstream → goal: integrate these modifications in
the tree
- git review net-next → goal: directly propose this change upstream
- git review <part_of_the_tree> → fix a topic of the tree
CI job:
- for the moment: only a mirror of net-next (base of the tree) →
easy to propose new Gerrit Changes that would go directly to net-next
(upstream) without going in our TopGit tree
- proposition: update the TopGit tree (for the moment empty) if no
error during merge/compilation/tests → Matthieu will look at that.
Netlink Patch:
- we might want to remove the subflow_error event → in case of
error, we cannot establish a new subflow immediately anyway, we need to
wait for the "close" event. → Matth will look at that
- Christoph has a fix when compiling it as a module (thx!)
- Ossama & Mat hasn't compared netlink APIs in detail yet
- could be nice to have some numbers (perf) for a server.
→ see the section 4.5:
https://www.tessares.net/wp-content/uploads/2016/06/SMAPP-Towards-Smart-M...
PM:
- for the server side, it might be good to have an eBPF "version",
this PM can be less "smart" (less interactions with other stuff in
userspace) but more powerful to do that directly in the kernel than
having to always announce the same address, etc.
mptcp_net-next/master:
- Mat is looking at updating it ; after the merge, when
disconnecting the app, le PM tried to re-established the subflows, strange
- v5 is then coming in our repo :)
Mat:
- also looking at the data-fin case and updating the patch-set
Next meeting:
- We propose to have the next one on Thursday, the 24th of January.
- Usual time: 17:00 UTC (9am PST, 6pm CET)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20190124
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
2 years, 9 months
MPTCP falling back to TCP
by Dejene Boru
Hi,
While running an experiment in Mininet using MPTCP, MPTCP falls back to TCP
after three SYN retransmissions. I have enabled MPTCP both on the host node
and Mininet emulated hosts. The problem appears when multiple clients
attempt to connect to the server, i.e., I have a client-server application,
the servers listen on a given port and the clients connect to the servers
at a certain time interval to download some file size (100KB, 30MB). A
connection with a client closes after the desired file size transfer but
the server continues to listen for new connections. The problem happens
after some number of clients are connected and irrespective of path
managers and the number of sub flows used.
I have tried to enable MPTCP to debug flag and the following debug message
is printed.
'mptcp_do_join_short:mpcb not found'
Host evnironment: Ubuntu 16.04, Linux version 4.14.79, MPTCP (v0.94)
Neither CPU nor memory seems to be part of the problem since during the
test the CPU usage is less than 10% and memory usage is also negligible.
I would appreciate a suggestion for a workaround for this issue.\
Thanks,
Dejene Boru
2 years, 9 months
