[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
4 years, 1 month
[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
4 years, 2 months
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
4 years, 2 months
[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.
4 years, 2 months
[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
4 years, 2 months
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
4 years, 2 months
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
4 years, 2 months
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.
4 years, 2 months
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
4 years, 2 months
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.
4 years, 3 months