From: Geliang Tang <geliangtang@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: mptcp@lists.linux.dev
Subject: Re: [MPTCP][PATCH v3 mptcp-next 1/8] mptcp: MP_FAIL suboption sending
Date: Wed, 14 Jul 2021 17:16:39 +0800 [thread overview]
Message-ID: <CA+WQbwt_76G1hVXmPUwbZXfraa=2KqBQAv1sYF17Bf=+V_mYSQ@mail.gmail.com> (raw)
In-Reply-To: <be269ef04813ede9084094b62f24d1fdcd7b91d0.camel@redhat.com>
Hi Paolo,
Thanks for your review!
Paolo Abeni <pabeni@redhat.com> 于2021年7月14日周三 下午4:45写道:
>
> On Mon, 2021-06-28 at 12:28 +0800, Geliang Tang wrote:
> > This patch added the MP_FAIL suboption sending support.
> >
> > Add a new flag named send_mp_fail in struct mptcp_subflow_context. If
> > this flag is set, send out MP_FAIL suboption.
> >
> > Add a new member fail_seq in struct mptcp_out_options to save the data
> > sequence number to put into the MP_FAIL suboption.
> >
> > Signed-off-by: Geliang Tang <geliangtang@gmail.com>
> > ---
> > include/net/mptcp.h | 1 +
> > net/mptcp/options.c | 54 ++++++++++++++++++++++++++++++++++++++++++--
> > net/mptcp/protocol.h | 4 ++++
> > 3 files changed, 57 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/net/mptcp.h b/include/net/mptcp.h
> > index cb580b06152f..f48d3b5a3fd4 100644
> > --- a/include/net/mptcp.h
> > +++ b/include/net/mptcp.h
> > @@ -72,6 +72,7 @@ struct mptcp_out_options {
> > u32 nonce;
> > u64 thmac;
> > u32 token;
> > + u64 fail_seq;
>
> Since we can't have both a valid mapping and MP_FAIL in the same
> packet, it would be better to avoid increasing the 'mptcp_out_options'
> size, e.g. re-using some ext_copy field, or unioning with some other
> field.
The RFC says an MP_FAIL option could be included in a RST or on the
subflow-level ACK. So I think we can't re-using the ext_copy field if it's
on the subflow-level ACK.
How about unioning this fail_seq field with ahmac field?
>
> mptcp_out_options has grown quite a bit and we should really look into
> shrinking it.
>
> > u8 hmac[20];
> > struct mptcp_ext ext_copy;
> > #endif
> > diff --git a/net/mptcp/options.c b/net/mptcp/options.c
> > index b5850afea343..b78defe1aed9 100644
> > --- a/net/mptcp/options.c
> > +++ b/net/mptcp/options.c
> > @@ -771,6 +771,28 @@ static noinline void mptcp_established_options_rst(struct sock *sk, struct sk_bu
> > opts->reset_reason = subflow->reset_reason;
> > }
> >
> > +static bool mptcp_established_options_mp_fail(struct sock *sk,
> > + unsigned int *size,
> > + unsigned int remaining,
> > + struct mptcp_out_options *opts)
> > +{
> > + struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(sk);
> > +
> > + if (!subflow->send_mp_fail)
> > + return false;
> > +
> > + if (remaining < TCPOLEN_MPTCP_FAIL)
> > + return false;
> > +
> > + *size = TCPOLEN_MPTCP_FAIL;
> > + opts->suboptions |= OPTION_MPTCP_FAIL;
> > + opts->fail_seq = subflow->fail_seq;
> > +
> > + pr_debug("MP_FAIL fail_seq=%llu", opts->fail_seq);
> > +
> > + return true;
> > +}
> > +
> > bool mptcp_established_options(struct sock *sk, struct sk_buff *skb,
> > unsigned int *size, unsigned int remaining,
> > struct mptcp_out_options *opts)
> > @@ -787,15 +809,29 @@ bool mptcp_established_options(struct sock *sk, struct sk_buff *skb,
> > return false;
> >
> > if (unlikely(skb && TCP_SKB_CB(skb)->tcp_flags & TCPHDR_RST)) {
> > - mptcp_established_options_rst(sk, skb, size, remaining, opts);
> > + if (mptcp_established_options_mp_fail(sk, &opt_size, remaining, opts)) {
> > + *size += opt_size;
> > + remaining -= opt_size;
> > + }
> > + mptcp_established_options_rst(sk, skb, &opt_size, remaining, opts);
> > + *size += opt_size;
> > + remaining -= opt_size;
> > return true;
> > }
> >
> > snd_data_fin = mptcp_data_fin_enabled(msk);
> > if (mptcp_established_options_mp(sk, skb, snd_data_fin, &opt_size, remaining, opts))
> > ret = true;
> > - else if (mptcp_established_options_dss(sk, skb, snd_data_fin, &opt_size, remaining, opts))
> > + else if (mptcp_established_options_dss(sk, skb, snd_data_fin, &opt_size, remaining, opts)) {
> > ret = true;
> > + if (opts->ext_copy.use_ack) {
>
> Is the extra check on 'opts->ext_copy.use_ack' necessary? can we just
> look for mp_fail?
>
I added this check since the RFC says an MP_FAIL option could be included
on the subflow-level ACK:
'''
In this case, if a receiver identifies a checksum failure when there is
only one path, it will send back an MP_FAIL option on the subflow-level
ACK, referring to the data-level sequence number of the start of the
segment on which the checksum error was detected.
'''
Do I understand right?
Thanks,
-Geliang
>
> > + if (mptcp_established_options_mp_fail(sk, &opt_size, remaining, opts)) {
> > + *size += opt_size;
> > + remaining -= opt_size;
> > + ret = true;
> > + }
> > + }
> > + }
> >
> > /* we reserved enough space for the above options, and exceeding the
> > * TCP option space would be fatal
> > @@ -1334,6 +1370,20 @@ void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
> > opts->backup, TCPOPT_NOP);
> > }
> >
> > + if (OPTION_MPTCP_FAIL & opts->suboptions) {
> > + const struct sock *ssk = (const struct sock *)tp;
> > + struct mptcp_subflow_context *subflow;
> > +
> > + subflow = mptcp_subflow_ctx(ssk);
> > + subflow->send_mp_fail = 0;
> > +
> > + *ptr++ = mptcp_option(MPTCPOPT_MP_FAIL,
> > + TCPOLEN_MPTCP_FAIL,
> > + 0, 0);
> > + put_unaligned_be64(opts->fail_seq, ptr);
> > + ptr += 2;
> > + }
> > +
> > if (OPTION_MPTCP_MPJ_SYN & opts->suboptions) {
> > *ptr++ = mptcp_option(MPTCPOPT_MP_JOIN,
> > TCPOLEN_MPTCP_MPJ_SYN,
> > diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> > index 426ed80fe72f..007af5e4ba3d 100644
> > --- a/net/mptcp/protocol.h
> > +++ b/net/mptcp/protocol.h
> > @@ -26,6 +26,7 @@
> > #define OPTION_MPTCP_FASTCLOSE BIT(8)
> > #define OPTION_MPTCP_PRIO BIT(9)
> > #define OPTION_MPTCP_RST BIT(10)
> > +#define OPTION_MPTCP_FAIL BIT(11)
> >
> > /* MPTCP option subtypes */
> > #define MPTCPOPT_MP_CAPABLE 0
> > @@ -67,6 +68,7 @@
> > #define TCPOLEN_MPTCP_PRIO_ALIGN 4
> > #define TCPOLEN_MPTCP_FASTCLOSE 12
> > #define TCPOLEN_MPTCP_RST 4
> > +#define TCPOLEN_MPTCP_FAIL 12
> >
> > #define TCPOLEN_MPTCP_MPC_ACK_DATA_CSUM (TCPOLEN_MPTCP_DSS_CHECKSUM + TCPOLEN_MPTCP_MPC_ACK_DATA)
> >
> > @@ -417,6 +419,7 @@ struct mptcp_subflow_context {
> > mpc_map : 1,
> > backup : 1,
> > send_mp_prio : 1,
> > + send_mp_fail : 1,
> > rx_eof : 1,
> > can_ack : 1, /* only after processing the remote a key */
> > disposable : 1; /* ctx can be free at ulp release time */
> > @@ -431,6 +434,7 @@ struct mptcp_subflow_context {
> > u8 reset_seen:1;
> > u8 reset_transient:1;
> > u8 reset_reason:4;
> > + u64 fail_seq;
> >
> > long delegated_status;
> > struct list_head delegated_node; /* link into delegated_action, protected by local BH */
>
next prev parent reply other threads:[~2021-07-14 9:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 4:28 [MPTCP][PATCH v3 mptcp-next 0/8] MP_FAIL support Geliang Tang
2021-06-28 4:28 ` [MPTCP][PATCH v3 mptcp-next 1/8] mptcp: MP_FAIL suboption sending Geliang Tang
2021-06-28 4:28 ` [MPTCP][PATCH v3 mptcp-next 2/8] mptcp: MP_FAIL suboption receiving Geliang Tang
2021-06-28 4:28 ` [MPTCP][PATCH v3 mptcp-next 3/8] mptcp: send out MP_FAIL when data checksum fail Geliang Tang
2021-06-28 4:29 ` [MPTCP][PATCH v3 mptcp-next 4/8] mptcp: add the mibs for MP_FAIL Geliang Tang
2021-06-28 4:29 ` [MPTCP][PATCH v3 mptcp-next 5/8] selftests: mptcp: add MP_FAIL mibs check Geliang Tang
2021-06-28 4:29 ` [MPTCP][PATCH v3 mptcp-next 6/8] mptcp: infinite mapping sending Geliang Tang
2021-06-28 4:29 ` [MPTCP][PATCH v3 mptcp-next 7/8] mptcp: infinite mapping receiving Geliang Tang
2021-06-28 4:29 ` [MPTCP][PATCH v3 mptcp-next 8/8] mptcp: add a mib for the infinite mapping sending Geliang Tang
2021-07-07 23:49 ` [MPTCP][PATCH v3 mptcp-next 7/8] mptcp: infinite mapping receiving Mat Martineau
2021-07-07 23:44 ` [MPTCP][PATCH v3 mptcp-next 6/8] mptcp: infinite mapping sending Mat Martineau
2021-07-08 0:44 ` Mat Martineau
2021-07-07 23:20 ` [MPTCP][PATCH v3 mptcp-next 3/8] mptcp: send out MP_FAIL when data checksum fail Mat Martineau
2021-07-13 12:44 ` Geliang Tang
2021-07-13 20:35 ` Mat Martineau
2021-07-14 3:56 ` Geliang Tang
2021-07-14 17:48 ` Mat Martineau
2021-07-07 23:07 ` [MPTCP][PATCH v3 mptcp-next 1/8] mptcp: MP_FAIL suboption sending Mat Martineau
2021-07-14 8:45 ` Paolo Abeni
2021-07-14 9:16 ` Geliang Tang [this message]
2021-07-14 15:49 ` Paolo Abeni
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='CA+WQbwt_76G1hVXmPUwbZXfraa=2KqBQAv1sYF17Bf=+V_mYSQ@mail.gmail.com' \
--to=geliangtang@gmail.com \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).