From: Florian Westphal <fw at strlen.de>
To: mptcp at lists.01.org
Subject: Re: [MPTCP] [PATCH RFC] mptcp: allow dumping subflow context to userspace
Date: Sat, 14 Sep 2019 12:09:02 +0200 [thread overview]
Message-ID: <20190914100902.GH10656@breakpoint.cc> (raw)
In-Reply-To: c2abb5d4494fb687eb394f7e5b90c35ee01060e2.camel@redhat.com
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
Davide Caratti <dcaratti(a)redhat.com> wrote:
> On Thu, 2019-09-12 at 18:50 +0200, Davide Caratti wrote:
> > add ulp-specific diagnostic functions, so that subflow information can be
> > dumped to userspace programs like 'ss'.
>
> for the record: iproute2 support is also on the way, but also in this case
> the first step will be in ktls. This patch exposes token, local/remote
> keys, and some of the bitfield members. What do you think it's reasonable
> exposing to users of 'ss -i' ?
The MPTCP (parent/meta) socket data, e.g. the DSS would be good.
Once Paolo retrans is in, we could also extend that to expose
information about MPTCP-Level events (rather than subflow stats).
This is a great start though. I guess it might be good to expose
how much more data the current mapping expects.
Wrt. local/remote keys, what is the use case?
I'm asking because some people get nervous when you add an api to
expose 'secret keys'.
If there is no clear use-case i'd rather not expose them for now,
it can be added later if needed.
next reply other threads:[~2019-09-14 10:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-14 10:09 Florian Westphal [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-09-18 10:47 [MPTCP] [PATCH RFC] mptcp: allow dumping subflow context to userspace Davide Caratti
2019-09-16 17:51 Matthieu Baerts
2019-09-16 13:33 Florian Westphal
2019-09-16 13:00 Davide Caratti
2019-09-12 17:34 Matthieu Baerts
2019-09-12 16:57 Davide Caratti
2019-09-12 16:50 Davide Caratti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190914100902.GH10656@breakpoint.cc \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.