From: Florian Westphal <fw@strlen.de>
To: Kishen Maloor <kishen.maloor@intel.com>
Cc: Florian Westphal <fw@strlen.de>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v5 5/8] mptcp: netlink: store per namespace list of refcounted listen socks
Date: Thu, 3 Feb 2022 21:35:52 +0100 [thread overview]
Message-ID: <20220203203552.GD4901@breakpoint.cc> (raw)
In-Reply-To: <1517e7e4-521b-6879-4846-024f53c86eaa@intel.com>
Kishen Maloor <kishen.maloor@intel.com> wrote:
> > Given that hook lives in an error path (from tcp point of view)
> > I think its going to be OK from a upstreaming point of view.
> >
> > It hopefully avoids the need for "magic listener sockets", and avoids
> > kernel fighting with userspace applications over which address:port
> > pairs are really useable.
> >
>
> Will this also obviate the need for listeners we currently create for port-based
> endpoints?
Hopefully yes.
> Indeed if there are active/legacy TCP deployments that cannot be reconfigured with the
> NO_LISTEN flag, then we could choose to stick with the current default behavior
> and introduce a LISTEN flag (and additionally a NO_LISTEN flag to not create listeners for
> port-based endpoints as discussed earlier today). Further, if it's possible, we could
> also update the MPTCP layer to not accept MPC attempts over listeners created in the
> kernel to address that matter?
Yes, we could do that, I suggest to wait and see how the "syn/join hook"
works out.
next prev parent reply other threads:[~2022-02-03 20:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-03 7:25 [PATCH mptcp-next v5 0/8] mptcp: fixes and enhancements related to path management Kishen Maloor
2022-02-03 7:25 ` [PATCH mptcp-next v5 1/8] mptcp: bypass in-kernel PM restrictions for non-kernel PMs Kishen Maloor
2022-02-03 7:25 ` [PATCH mptcp-next v5 2/8] mptcp: store remote id from MP_JOIN SYN/ACK in local ctx Kishen Maloor
2022-02-03 7:25 ` [PATCH mptcp-next v5 3/8] mptcp: reflect remote port (not 0) in ANNOUNCED events Kishen Maloor
2022-02-03 7:25 ` [PATCH mptcp-next v5 4/8] mptcp: establish subflows from either end of connection Kishen Maloor
2022-02-03 7:25 ` [PATCH mptcp-next v5 5/8] mptcp: netlink: store per namespace list of refcounted listen socks Kishen Maloor
2022-02-03 17:46 ` Florian Westphal
2022-02-03 20:09 ` Kishen Maloor
2022-02-03 20:35 ` Florian Westphal [this message]
2022-02-04 1:02 ` Mat Martineau
2022-02-04 9:47 ` Paolo Abeni
2022-02-03 7:25 ` [PATCH mptcp-next v5 6/8] mptcp: netlink: store lsk ref in mptcp_pm_addr_entry Kishen Maloor
2022-02-16 3:56 ` Geliang Tang
2022-02-03 7:25 ` [PATCH mptcp-next v5 7/8] mptcp: attempt to add listening sockets for announced addrs Kishen Maloor
2022-02-04 13:52 ` Geliang Tang
2022-02-03 7:25 ` [PATCH mptcp-next v5 8/8] mptcp: expose server_side attribute in MPTCP netlink events Kishen Maloor
2022-02-03 7:38 ` mptcp: expose server_side attribute in MPTCP netlink events: Build Failure MPTCP CI
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=20220203203552.GD4901@breakpoint.cc \
--to=fw@strlen.de \
--cc=kishen.maloor@intel.com \
--cc=mptcp@lists.linux.dev \
/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.