| Message ID | 20220427225002.231996-1-mathew.j.martineau@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mptcp: Path manager mode selection | expand |
On Wed, 27 Apr 2022 15:49:56 -0700 Mat Martineau wrote: > MPTCP already has an in-kernel path manager (PM) to add and remove TCP > subflows associated with a given MPTCP connection. This in-kernel PM has > been designed to handle typical server-side use cases, but is not very > flexible or configurable for client devices that may have more > complicated policies to implement. > > This patch series from the MPTCP tree is the first step toward adding a > generic-netlink-based API for MPTCP path management, which a privileged > userspace daemon will be able to use to control subflow > establishment. These patches add a per-namespace sysctl to select the > default PM type (in-kernel or userspace) for new MPTCP sockets. New > self-tests confirm expected behavior when userspace PM is selected but > there is no daemon available to handle existing MPTCP PM events. > > Subsequent patch series (already staged in the MPTCP tree) will add the > generic netlink path management API. Could you link to those patches, maybe? Feels a little strange to add this sysctl to switch to user space mode now, before we had a chance to judg^W review the netlink interface. Does the pm_type switch not fit more neatly into the netlink interface itself?
On Thu, 28 Apr 2022, Jakub Kicinski wrote: > On Wed, 27 Apr 2022 15:49:56 -0700 Mat Martineau wrote: >> MPTCP already has an in-kernel path manager (PM) to add and remove TCP >> subflows associated with a given MPTCP connection. This in-kernel PM has >> been designed to handle typical server-side use cases, but is not very >> flexible or configurable for client devices that may have more >> complicated policies to implement. >> >> This patch series from the MPTCP tree is the first step toward adding a >> generic-netlink-based API for MPTCP path management, which a privileged >> userspace daemon will be able to use to control subflow >> establishment. These patches add a per-namespace sysctl to select the >> default PM type (in-kernel or userspace) for new MPTCP sockets. New >> self-tests confirm expected behavior when userspace PM is selected but >> there is no daemon available to handle existing MPTCP PM events. >> >> Subsequent patch series (already staged in the MPTCP tree) will add the >> generic netlink path management API. > > Could you link to those patches, maybe? Feels a little strange to add > this sysctl to switch to user space mode now, before we had a chance > to judg^W review the netlink interface. > Hi Jakub - Sure, no problem. If you'd prefer a pull request for this feature as a whole I could stage that. Here's a tag (note: do not merge this as-is, the committer ids and full history aren't suitable) -> https://github.com/multipath-tcp/mptcp_net-next/commits/netdev-review-userspace-path-manager The last 26 commits there cover the full userspace path manager kernel code, with the first 6 of those being this series. Userspace path managers makes use of generic netlink MPTCP events that have already been upstream for a while, and the full series adds four netlink commands for userspace: * MPTCP_PM_CMD_ANNOUNCE: advertise an address that's available for additional subflow connections. * MPTCP_PM_CMD_REMOVE: revoke an advertisement * MPTCP_PM_CMD_SUBFLOW_CREATE: initiate a new subflow on an existing MPTCP connection * MPTCP_PM_CMD_SUBFLOW_DESTROY: close a subflow on an existing MPTCP connection There's one commit for each command, each with an obvious title ("mptcp: netlink: Add MPTCP_PM_CMD_<name>") > Does the pm_type switch not fit more neatly into the netlink interface > itself? We (on the MPTCP ML) did discuss that as a design option, and landed on the sysctl. The stack can handle having no userspace PM daemon present since MPTCP connections can still be initiated without the PM and operate in single subflow mode at first. When the daemon starts up later it can manage the existing sockets and start announcing addresses or adding subflows. We wanted to avoid accidentally ending up with a mix of kernel-PM-managed and userspace-PM-managed sockets depending on when the daemon loaded. Userspace PM daemons could depend on carrier policy or other complex dependencies, so it made sense to allow setting the sysctl early and leave more flexibility for launching the daemon later. -- Mat Martineau Intel
On Thu, 28 Apr 2022 20:39:01 -0700 (PDT) Mat Martineau wrote: > Sure, no problem. If you'd prefer a pull request for this feature as a > whole I could stage that. > > Here's a tag (note: do not merge this as-is, the committer ids and full > history aren't suitable) -> > https://github.com/multipath-tcp/mptcp_net-next/commits/netdev-review-userspace-path-manager > > The last 26 commits there cover the full userspace path manager kernel > code, with the first 6 of those being this series. > > Userspace path managers makes use of generic netlink MPTCP events that > have already been upstream for a while, and the full series adds four > netlink commands for userspace: > > * MPTCP_PM_CMD_ANNOUNCE: advertise an address that's available for > additional subflow connections. > > * MPTCP_PM_CMD_REMOVE: revoke an advertisement > > * MPTCP_PM_CMD_SUBFLOW_CREATE: initiate a new subflow on an existing MPTCP > connection > > * MPTCP_PM_CMD_SUBFLOW_DESTROY: close a subflow on an existing MPTCP > connection > > There's one commit for each command, each with an obvious title ("mptcp: > netlink: Add MPTCP_PM_CMD_<name>") Thanks for the explanation, applied!
Hello: This series was applied to netdev/net-next.git (master) by Jakub Kicinski <kuba@kernel.org>: On Wed, 27 Apr 2022 15:49:56 -0700 you wrote: > MPTCP already has an in-kernel path manager (PM) to add and remove TCP > subflows associated with a given MPTCP connection. This in-kernel PM has > been designed to handle typical server-side use cases, but is not very > flexible or configurable for client devices that may have more > complicated policies to implement. > > This patch series from the MPTCP tree is the first step toward adding a > generic-netlink-based API for MPTCP path management, which a privileged > userspace daemon will be able to use to control subflow > establishment. These patches add a per-namespace sysctl to select the > default PM type (in-kernel or userspace) for new MPTCP sockets. New > self-tests confirm expected behavior when userspace PM is selected but > there is no daemon available to handle existing MPTCP PM events. > > [...] Here is the summary with links: - [net-next,1/6] mptcp: Remove redundant assignments in path manager init https://git.kernel.org/netdev/net-next/c/9273b9d57995 - [net-next,2/6] mptcp: Add a member to mptcp_pm_data to track kernel vs userspace mode https://git.kernel.org/netdev/net-next/c/d85a8fde71e2 - [net-next,3/6] mptcp: Bypass kernel PM when userspace PM is enabled https://git.kernel.org/netdev/net-next/c/14b06811bec6 - [net-next,4/6] mptcp: Make kernel path manager check for userspace-managed sockets https://git.kernel.org/netdev/net-next/c/6961326e38fe - [net-next,5/6] mptcp: Add a per-namespace sysctl to set the default path manager type https://git.kernel.org/netdev/net-next/c/6bb63ccc25d4 - [net-next,6/6] selftests: mptcp: Add tests for userspace PM type https://git.kernel.org/netdev/net-next/c/5ac1d2d63451 You are awesome, thank you!