March 2018 - mptcp - Ml01.01.Org

[PATCH 00/12] Make subflow establishment lockless

by Christoph Paasch

The most recent TCP stack supports lockless listeners. For MPTCP, we however are still taking the meta-lock when creating new subflows (cfr., tcp_v4_rcv and mptcp_lookup_join). This patchset makes subflow establishment lockless by using lockless procedures in the stack, RCU-lists, atomic operations,... Christoph Paasch (12): mptcp: Cleanup mptcp: Improved debugging mptcp: Use correct tcp_queue when calling mptcp_fragment mptcp: Use mptcp_can_new_subflow where possible mptcp: Render mptcp_sub_inherit_sockopts lockless mptcp: Make mptcp_set_new_pathindex lockless mptcp: Remove cnt_subflows mptcp: Remove cnt_established mptcp: Rename tw_lock to mpcb_list_lock mptcp: Make subflow-list an RCU-list mptcp: Don't take meta-lock when receiving third ACK mptcp: Make mptcp_do_join_short and mptcp_lookup_join lockless include/net/mptcp.h | 120 ++++++++++----------------- net/ipv4/af_inet.c | 9 ++- net/ipv4/ip_sockglue.c | 7 +- net/ipv4/tcp.c | 31 ++++--- net/ipv4/tcp_ipv4.c | 41 +--------- net/ipv4/tcp_minisocks.c | 9 ++- net/ipv6/tcp_ipv6.c | 41 +--------- net/mptcp/mctcp_desync.c | 22 ++--- net/mptcp/mptcp_balia.c | 21 ++--- net/mptcp/mptcp_binder.c | 23 +++++- net/mptcp/mptcp_coupled.c | 52 +++++------- net/mptcp/mptcp_ctrl.c | 187 ++++++++++++++++++++++++++++--------------- net/mptcp/mptcp_fullmesh.c | 30 ++++--- net/mptcp/mptcp_input.c | 150 ++++++++++++---------------------- net/mptcp/mptcp_ipv4.c | 34 +++----- net/mptcp/mptcp_ipv6.c | 15 ++-- net/mptcp/mptcp_ndiffports.c | 17 +++- net/mptcp/mptcp_olia.c | 28 ++++--- net/mptcp/mptcp_output.c | 50 ++++++++---- net/mptcp/mptcp_redundant.c | 151 +++++++++++++++++++++++++++------- net/mptcp/mptcp_rr.c | 22 +++-- net/mptcp/mptcp_sched.c | 32 ++++---- net/mptcp/mptcp_wvegas.c | 5 +- 23 files changed, 586 insertions(+), 511 deletions(-) -- 2.16.2

2 years, 11 months

2
29
0 / 0

[RFC 0/9] Changes for implementing MPTCP

by rao.shoaib＠oracle.com

From: Rao Shoaib <rao.shoaib(a)oracle.com> Following patches modify TCP code to enable implementation of MPTCP. MPTCP implementation requires sharing of TCP code with minor modification here and there. In order to keep the TCP code clean and easy to maintain, common code has been moved to new functions for use by both TCP and MPTCP. struct tcp_sock now has function pointers and based on the socket type (TCP/MPTCP) appropriate function is called. A basic implementation of MPTCP that works with IPv4/IPv6 and supports join has been tested based on these changes. The changes are being submitted as an RFC to get feedback from the community and to start a discussion on how to move forward. Rao Shoaib (9): Modify tcp structures to support function pointers Introduce MPTCP specific elements that will co-exist with TCP even when MPTCP is not compiled Introduce MPTCP specific elements that can be under #ifdef MPTCP_CONFIG Populate function pointers -- few (5) will be populated later Switch code to use function pointers Make TCP options processing abstract Restructure syncookie code to use pointers Restructure TCP code so that it can be shared primarily with MPTCP Add MPTCP specific code to core TCP code crypto/md5.c | 3 - include/crypto/md5.h | 2 + include/linux/tcp.h | 91 ++++++++++++ include/net/inet_common.h | 2 + include/net/inet_sock.h | 6 +- include/net/net_namespace.h | 6 + include/net/secure_seq.h | 9 +- include/net/sock.h | 1 + include/net/tcp.h | 321 ++++++++++++++++++++++++++++++++++++++-- include/net/tcp_states.h | 4 +- include/net/transp_v6.h | 3 - include/uapi/linux/bpf.h | 4 +- include/uapi/linux/if.h | 5 + include/uapi/linux/tcp.h | 1 + net/core/secure_seq.c | 70 +++++++++ net/ipv4/af_inet.c | 16 +- net/ipv4/inet_connection_sock.c | 17 ++- net/ipv4/ip_sockglue.c | 20 +++ net/ipv4/syncookies.c | 112 ++++++++++---- net/ipv4/tcp.c | 221 +++++++++++++++++++++------ net/ipv4/tcp_input.c | 195 ++++++++++++++---------- net/ipv4/tcp_ipv4.c | 112 ++++++++++---- net/ipv4/tcp_minisocks.c | 56 ++++++- net/ipv4/tcp_output.c | 206 +++++++++++++++----------- net/ipv4/tcp_timer.c | 55 +++++-- net/ipv6/af_inet6.c | 4 +- net/ipv6/ipv6_sockglue.c | 14 ++ net/ipv6/syncookies.c | 40 +---- net/ipv6/tcp_ipv6.c | 163 +++++++++++++------- 29 files changed, 1360 insertions(+), 399 deletions(-) -- 2.7.4

3 years

5
50
0 / 0

Socket layer changes to MPTCP

by Rao Shoaib

I have recently noticed that the group is working on socket level changes to MPTCP. Can a summary of the issues and how the changes will solve them be posted to the list? That would help any new participants as well. If they have already been discussed please point me to the thread. It will also help if it can be made clear how these changes will expedite implementation of a basic MPTCP implementation. I believe that is the current goal, but my understanding may be incorrect. Thanks, Shoaib

3 years

2
8
0 / 0

[Weekly meetings] MoM - 29th of March 2018

by Matthieu Baerts

Hello, We just had our 4th meeting with Mat and Peter (Intel OTC), Christoph (Apple) and myself (Tessares). Thanks again for this new good meeting! Here are the minutes of the meeting: - discussion of Rao Shoaib's patches: - Christoph posted some comments - Peter has comments but mainly similar to the ones of Christoph. Will try to post comments the coming days. - Rao was not able to join, we hope we will be able to discuss about reviews that were done for these patches (or a v2) next week. - Netlink PM (Matthieu's patches) * Discussion on missed events: it is very rare. A bit like loosing UDP packets between apps on the same host. We can have a PM with Netlink. Could be interesting to get stats of lost events. * _CREATED vs. _ESTABLISHED: we would like to have a simple v1, with only the minimum required. Not having the _CREATED event could be OK, we would not announce ADD_ADDR ASAP but on the other hand, if the client receives this while the session is not "ESTABLISHED", it cannot create a second subflow. * Goal: simple API that can be extended later. * (lot of discussions about that but it was difficult to take notes at the same points for me). - lockless subflows (Christoph's patches) - one more fix coming - waiting for review - Mat and Peter's patches: - first design is there - will simplify (a lot) the current implementation, at least on the client side. The tricky side is the server side. Work will need to be done on this area. Peter is looking at this. - Server side: biggest issue: allocate socket for new (coming) subflows. Subflows need to be attached to the MPTCP connection. Idea (dirty) from Christoph is to pre-allocate resources. Current way of doing that (https://github.com/multipath-tcp/mptcp): resources are allocated at the 3rd ACK. Here we would need to do the kernel's accept() in usercontext but also allocate and attach resources to the MPTCP connection. What to do in the meantime? We cannot drop data. The subflow should be seen as fully-functional even if it is not properly accepted/attached. - Note about these patches: it is a RFC, we agreed in the past to share patches as soon as possible to comment about the idea. - waiting for review on the ML - Mat's summary: - clear - was added in MPTCP's wiki - netdevconf: - Because David will not be there, maybe a tutorial is more interesting. Goad: Why MPTCP is interesting, why netdev community should look at, what we are doing in the upstreaming process. - Maybe good to have a dedicated topic in the ML (but already a lot of other messages there, that can wait) - Tutorial: some ideas - Android smartphones with MPTCP (but you will need SIM cards, etc.) - Raspberry PI with MPTCP: they have two ifaces now but maybe hard to setup / have something working - safer to have a VM? - (last time, there were tutorial where people were only looking, not acting → we can also show what's happening with some embedded devices) - could be good to have new ideas. - deadline is May, we still have one month to think about that. - Next steps: - Our ML is not very visible. Wiki: we can use Github. - We could move stuff to Github (https://github.com/multipath-tcp/mptcp), wiki included. - Could be good to have a wiki because there are already a lot of discussions in the ML. Mat confirmed he can edit the wiki at https://github.com/multipath-tcp/mptcp/wiki - most of the next steps concern the continuation of the discussions on the different topics already opened on the ML (mostly linked to big patch-set) - people will try to find time -- among other priorities -- to review them. Next meeting: - proposition: the 5th of April at 16:00 UTC (9am PDT, 6pm CEST) - open to everyone! - https://annuel2.framapad.org/p/mptcp_upstreaming_20180405 Feel free to comment 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 -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

3 years

2
1
0 / 0

[RFC PATCH 00/16] MPTCP architecture proposal for discussion

by Mat Martineau

Hello everyone, Peter and I have been working on this patch set to show how how MPTCP can fit in to the Linux networking stack while using these design ideas: * Applications opt-in to MPTCP using IPPROTO_MPTCP, regular TCP sockets are still the default. A socket created with socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP) will attempt to form a MPTCP connection. IPPROTO_MPTCP == 99 as a placeholder. * Subflows exist within the kernel as separate sockets, owned by a MPTCP connection-level socket that is visible to userspace. * Adds an optional area to struct sk_buff to store MPTCP metadata without increasing the size of normal sk_buffs. * Adds the CONFIG_MPTCP option to Kconfig. The following patches can form an MPTCP connection with the multipath-tcp.org kernel (tested with v0.94), and send DSS mappings that are accepted for the initial data packet. It is an early implementation, and I don't represent it as being upstreamable as-is or being everyone's idea of what an eventual upstream implementation will necessarily look like. It has significant limitations: * Only one subflow is supported, no joins, and only ipv4. * Does not support DSS checksums. Checksums must be disabled on the remote stack (for multipath-tcp.org, 'sudo sysctl -w net.mptcp.mptcp_checksum=0') * Lots of debug statements (although they use dynamic debug and are disabled by default) and TODOs. * The connection falls back to TCP after the first data packet because there's no MPTCP option on the ack after the handshake completes and the first data is exchanged. * It's only been tested sending small amounts of data, and will reject system calls attempting to write more data than can fit in one mapping. I should have an additional patch soon that handles the receive path (getting the MPTCP option up to the connection level socket to parse and handle mappings) and adds the MPTCP option to ACK packets. Hopefully there are are some interesting concepts to discuss, and this code helps us assess how workable the above design principles are. Thanks in advance for your feedback on the benefits or drawbacks of this code, how it might be improved, or how other approaches might compare. The patch set applies to net-next (as of commit 5d22d47b9ed96e on 2018-03-27). I have also pushed it to: https://git.kernel.org/pub/scm/linux/kernel/git/martineau/linux.git (mptcp-proposal branch) Mat Martineau (6): tcp: Add MPTCP option number tcp: Define IPPROTO_MPTCP skbuff: Add shared control buffer tcp: Export low-level TCP functions mptcp: More efficient byte order handling mptcp: Write MPTCP DSS headers to outgoing data packets Peter Krystad (10): mptcp: Add MPTCP socket stubs mptcp: Handle MPTCP TCP options tcp: Add IPPROTO_SUBFLOW tcp: expose tcp routines and structs for MPTCP mptcp: Create SUBFLOW socket for outgoing connections mptcp: Create SUBFLOW socket for incoming connections mptcp: Add key generation and token tree mptcp: Add getname() socket operation mptcp: Add shutdown() socket operation mptcp: Implement setsockopt()/getsockopt() include/linux/skbuff.h | 24 +- include/linux/tcp.h | 14 + include/net/inet_common.h | 3 + include/net/mptcp.h | 177 ++++++++++++ include/net/tcp.h | 8 + include/uapi/linux/in.h | 4 + net/Kconfig | 1 + net/Makefile | 1 + net/core/skbuff.c | 53 +++- net/ipv4/af_inet.c | 2 +- net/ipv4/tcp.c | 12 +- net/ipv4/tcp_input.c | 15 ++ net/ipv4/tcp_ipv4.c | 4 +- net/ipv4/tcp_output.c | 184 ++++++++++++- net/mptcp/Kconfig | 10 + net/mptcp/Makefile | 3 + net/mptcp/crypto.c | 209 ++++++++++++++ net/mptcp/options.c | 177 ++++++++++++ net/mptcp/protocol.c | 673 ++++++++++++++++++++++++++++++++++++++++++++++ net/mptcp/subflow.c | 351 ++++++++++++++++++++++++ net/mptcp/token.c | 222 +++++++++++++++ 21 files changed, 2121 insertions(+), 26 deletions(-) create mode 100644 include/net/mptcp.h create mode 100644 net/mptcp/Kconfig create mode 100644 net/mptcp/Makefile create mode 100644 net/mptcp/crypto.c create mode 100644 net/mptcp/options.c create mode 100644 net/mptcp/protocol.c create mode 100644 net/mptcp/subflow.c create mode 100644 net/mptcp/token.c -- 2.16.3

3 years

4
24
0 / 0

How function pointers will be replaced

by Rao Shoaib

I am in the process of replacing function pointers with a macro that calls the appropriate function based on the socket. Mat, suggested that I share what it looks like. So here it is. The current code in the patch: /* Send _single_ skb sitting at the send head. This function requires * true push pending frames to setup probe timer etc. */ void tcp_push_one(struct sock *sk, unsigned int mss_now) { struct sk_buff *skb = tcp_send_head(sk); BUG_ON(!skb || skb->len < mss_now); tcp_sk(sk)->op_ops->write_xmit(sk, mss_now, TCP_NAGLE_PUSH, 1, sk->sk_allocation); } After my fix to not use function pointers it will look like /* Send _single_ skb sitting at the send head. This function requires * true push pending frames to setup probe timer etc. */ void tcp_push_one(struct sock *sk, unsigned int mss_now) { struct sk_buff *skb = tcp_send_head(sk); BUG_ON(!skb || skb->len < mss_now); CALL_ONE(tcp_write_xmit, sk, mss_now, TCP_NAGLE_PUSH, 1, sk->sk_allocation); } /* Macro to call appropriate function depending upon the socket type. * First two arguments are required to be the name of the function called and socket * pointer respectively. Any other arguments are optional as required by * the called function. */ #define CALL_ONE(fn, __sk, ...) \ (likely (!tcp_sk(__sk)->tcp_alt) ? \ (fn)(__sk, ##__VA_ARGS__) : (mp##fn)(__sk, ##__VA_ARGS__)) I am not happy about this as function pointers kept the code cleaner. If anyone has better ideas or see any issues please speak up so I can make the change now than later. Thanks, Shoaib

3 years

2
2
0 / 0

Using struct socket for subflows

by Christoph Paasch

Hello, (first, sorry for the long e-mail) I now started working on cleaning up the input path to prepare it for input-processing without holding the MPTCP-level lock. To do this, I go through all the places where we access data-structures from the meta-socket and see if I can move it to mptcp_data_ready or mptcp_write_space (the callbacks that are called from sk_data_ready/sk_write_space). In tcp_check_space() we have the following: if (mptcp(tcp_sk(sk)) || (sk->sk_socket && test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))) { tcp_new_space(sk); if (sk->sk_socket && !test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) tcp_chrono_stop(sk, TCP_CHRONO_SNDBUF_LIMITED); } We do the if (mptcp(...)), because currently subflow's sk_socket is pointing to application's struct socket. Thus, we need to avoid the check for SOCK_NOSPACE, as otherwise we might end up not calling sk_write_space. Other kernel-modules that create TCP-connections rather have an in-kernel struct socket. And modules like RDS even force SOCK_NOSPACE to be set, such that the TCP-stack keeps on up-calling. I thought that this was a good thing to do in MPTCP as well. So, my goal became to have a fully functional struct socket for subflows. The benefit is also that we can end up using kernel_sendmsg, kernel_recvmsg,... in the future. It also allows to do kernel_accept() on the MPTCP-level socket to receive new subflows (a problem I mentioned in an earlier mail). It also would allow us to expose subflows as file-descriptors to the user-space. That way the user-space can do setsockopt, getsockopt,... on the subflows. An idea that came up in the past when we were thinking on how to expose an MPTCP API that allows apps to control certain things on the subflows. To get there, there are a few places where things would need to change: * mptcp_init4_subsockets - Here, this works perfectly. It also allows to avoid "faking" the struct socket, as we are currently doing. * mptcp_alloc_mpcb for the active opener - This is the first problem. mptcp_alloc_mpcb() can be called with bh disabled. But sock_create_lite() assumes that bh is enabled as it ends up doing an alloc with GFP_KERNEL. A few ways this could be solved: - Schedule a work-queue item in mptcp_alloc_mpcb that creates the struct socket. This looks a bit racy to me. Not sure what side-effects this might have. - Change things entirely, such that the master-sock is being allocated when the connection is created. That way, we allocate all the necessary struct socket's right away. In the past, we decided to allocate the master-sk only when receiving the SYN/ACK. We did that so as to minimize the impact on regular TCP when the server does not support MPTCP. But, as we are moving towards explicitly exposing MPTCP at the socket-layer, we can rethink that decision. Any thoughts? Is it ok to pay the cost of allocating a master-sk before we know whether the server supports MPTCP? I think, we should do this, and transition to that model. * mptcp_alloc_mpcb for the passive opener - same problem as above but on the other side. We could allocate the master's struct socket upon the accept() call from the application. This again sounds a bit racy to me. The struct socket will be there for the subflow potentially much later than it has been established. What happens if the peer sends data or an MP_FASTCLOSE,... ? * New subflows on the passive opener side - again, we are receiving those subflows while bh is disabled. So, we have to schedule a work-queue to do a kerne_accept() on the MPTCP-socket. Again something that can potentially be racy. In general, subflow-establishment on the passive-opener side again seems to be a major pain-point. I think, we really need to redesign that. Any thoughts, feedback, suggestions? Or maybe, using real struct socket for subflows is not worth it? :) Thanks, Christoph

3 years

5
12
0 / 0

Weekly meeting - 29 March 2018 16:00 UTC (9am PDT, 6pm CEST)

by Matthieu Baerts

Hello, Our public MPTCP upstreaming weekly web conference is scheduled for tomorrow. The list of topics is here: https://annuel2.framapad.org/p/mptcp_upstreaming_20180329 Feel free to add/modify topics! Meeting link: https://talky.io/mptcp_upstreaming Speak to you tomorrow! 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 -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

3 years

2
3
0 / 0

Status and what's next

by Mat Martineau

Hello everyone - In our recent web conference call, we thought it would be helpful to summarize what is coming up for MPTCP upstreaming. To start, I'd like to review work that's already been done and is underway. Previous work: * Mat developed an extensible TCP option framework patch, and Christoph refactored upstream TCP-MD5 and SMC functionality to use it. The idea was to integrate some extensions in to TCP that had utility for existing functionality, but would also help integrate MPTCP. This RFC patch set was turned down by Dave Miller, but did give us useful guidance. * Mat published a proposal for optionally extending sk_buff shared info to carry MPTCP metadata. Ongoing work: * Christoph keeps the multipath-tcp.org kernel merged with recent kernel releases as part of his maintainership role for the multipath-tcp.org project, and is refactoring parts of the MPTCP implementation to take advantage of newer kernel or TCP features and to align with upstreaming goals. * Rao has published an RFC patch set based on the multipath-tcp.org MPTCP implementation and the current upstream kernel, with modifications to make the TCP implementation extensible in a way that's useful for MPTCP. It is currently under review by community members. * Matthieu has sent a generic netlink patch set to mptcp-dev. * Ossama shared a generic netlink path management API proposal. The Intel group developed this before we knew Matthieu would be sharing an implementation. * Stephan shared a userspace path manager draft implementation at https://github.com/brenns10/pathmand * Peter and Mat are preparing a patch set showing an MPTCP architecture with a separate socket type for the MPTCP connection and using in-kernel TCP sockets for subflows. The extended sk_buff structure patch is part of this. * Ossama has made significant progress on a userspace path manager implementation with the goal to open source it That gives us quite a bit to discuss and review on the list in the near term. The bigger and longer-term challenge is to take these pieces and develop a strategy and patches for upstream submissions. There are a few things the MPTCP upstreaming community members on this list seem aligned on: * MPTCP belongs in the upstream kernel * The multipath-tcp.org implementation is not upstream-ready as-is * Implementing 100% from scratch is not the preferred strategy How do we get to upstreamable patch sets from here? I think if we can agree on what an upstreamable MPTCP architecture looks we can evaluate patch sets accordingly. I've proposed these design characteristics before, but the mailing list has expanded significantly since then: * MPTCP is used when requested by the application, either through an IPPROTO_MPTCP parameter to socket() or by using the new ULP (Upper Layer Protocol) capability. * Move away from meta-sockets, treating each subflow more like a regular TCP connection. The overall MPTCP connection is coordinated by an upper layer socket that is distinct from tcp_sock. * Move functionality to userspace where possible, like tracking ADD_ADDRs received, initiating new subflows, or accepting new subflows. * Avoid adding locks to coordinate access to data that's shared between subflows. Utilize capabilities like compare-and-swap (cmpxchg), atomics, and RCU to deal with shared data efficiently. Are these the right place to start? Anyone want to expand the list? Thanks, -- Mat Martineau Intel OTC

3 years

3
3
0 / 0

Fwd: Re: Few questions about submitting patches

by Rao Shoaib

There has been some misunderstanding on what an RFC patch is and what standards it needs to meet. Following is the official response of David Miller. Based on those guidelines the RFC patch we submitted meets and exceeds the requirements. So please review it. Replacement of function pointers will be addressed later as a separate issue. In case there are other procedural issues that would prohibit technical discussion please site the written rules or first ask David Miller. There are a lot of technical issues to discuss, so if possible lets not get tied up on process and bureaucracy. Looking forward to detailed technical comments. Shoaib -------- Forwarded Message -------- Subject: Re: Few questions about submitting patches Date: Wed, 21 Mar 2018 12:46:17 -0400 (EDT) From: David Miller <davem(a)davemloft.net> To: rao.shoaib(a)oracle.com CC: netdev(a)vger.kernel.org, eric.dumazet(a)gmail.com From: Rao Shoaib <rao.shoaib(a)oracle.com> Date: Wed, 21 Mar 2018 09:41:13 -0700 > I am new to Linux. I would like to understand the rules and etiquettes > of engaging with the community. I have read the materials that I could > find. As I work with Linux I come across situations for which I can > not seem to find any answers. Hopefully folks on the list can answer > them. > > * Submitting an RFC Patch > > As I understand, an RFC patch is submitted to solicit comments and is > not for inclusion. Is it sufficient for an RFC patch to have the > correct coding style and compile, or does it need more? For example, > If the patch consists of a series of patches, does each patch have to > compile independently etc etc. It should build and function, unless you explicitly state that the patch is not build nor functionally tested and is intended to show the design of the change. > * #ifdef FOO > > In a regular patch consisting of a series of patches, can the above > #ifdef be used in a patch before the patch that allows the selection > of FOO. That patch is part of the series but comes later. It is better to introduce them at the same time. But if it is prohibitively difficult to do so, yet at the same time properly split up your changes into manageable pieces, it can be OK. It is definitely determined on a case by case basis.

3 years

3
3
0 / 0

2021

2020

2019

2018

2017

mptcp March 2018