All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hangbin Liu <hangbin.liu@linux.dev>
To: Matthieu Baerts <matttbe@kernel.org>
Cc: Hangbin Liu <liuhangbin@kylinos.cn>, MPTCP Linux <mptcp@lists.linux.dev>
Subject: Re: [PATCH mptcp-next 2/2] selftests: mptcp: convert iptables to nftables for mptcp_join.sh
Date: Thu, 3 Sep 2026 10:02:46 +0800	[thread overview]
Message-ID: <apjU-uM8dvxnVcaP@fedora> (raw)
In-Reply-To: <513e6559-a06a-45d8-a8b7-72b3a1a77e71@kernel.org>

Hi Matthieu,

Sorry, My mbsync has some delays and I post v2 too quick before catching
your feedback. I will update the patch with your feed back and re-post
tomorrow.

On Wed, Sep 02, 2026 at 12:00:40PM +0200, Matthieu Baerts wrote:
> > The iptables/ip6tables check inside mptcp_lib.sh is kept in case any
> > one still need them.
> 
> Please remove them, not to be tempted to use them.

OK, I will.

> 
> > Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
> > ---
> >  tools/testing/selftests/net/mptcp/config        |   3 +
> >  tools/testing/selftests/net/mptcp/mptcp_join.sh | 136 +++++++++---------------
> >  2 files changed, 51 insertions(+), 88 deletions(-)
> > 
> > diff --git a/tools/testing/selftests/net/mptcp/config b/tools/testing/selftests/net/mptcp/config
> > index 59051ee2a986..0d0a744c4ca8 100644
> > --- a/tools/testing/selftests/net/mptcp/config
> > +++ b/tools/testing/selftests/net/mptcp/config
> > @@ -30,6 +30,9 @@ CONFIG_NET_SCH_NETEM=m
> >  CONFIG_NF_TABLES=m
> >  CONFIG_NF_TABLES_INET=y
> >  CONFIG_NFT_COMPAT=m
> > +CONFIG_NFT_NUMGEN=y
> > +CONFIG_NFT_REJECT=m
> > +CONFIG_NFT_REJECT_IPV4=m
> 
> Even if we currently don't need the v6 version, I wonder if we shouldn't
> add it here. Up to you, when we will need it, we can also add it here, fine.
> 
> I wonder if we shouldn't remove the ones linked to IPTables. I was
> thinking that maybe we could keep them for debug purposes, but same as
> the reject v6, we can add them when required instead of guessing which
> ones would be useful, "just in case". So yes, do you mind removing the
> ones that are no longer needed, please?

OK, I will

> > -# IPv4: TCP hdr of 48B, a first suboption of 12B (DACK8), the RM_ADDR suboption
> > -# generated using "nfbpf_compile '(ip[32] & 0xf0) == 0xc0 && ip[53] == 0x0c &&
> > -#				  (ip[66] & 0xf0) == 0x40'"
> > -CBPF_MPTCP_SUBOPTION_RM_ADDR="13,
> > -			      48 0 0 0,
> > -			      84 0 0 240,
> > -			      21 0 9 64,
> > -			      48 0 0 32,
> > -			      84 0 0 240,
> > -			      21 0 6 192,
> > -			      48 0 0 53,
> > -			      21 0 4 12,
> > -			      48 0 0 66,
> > -			      84 0 0 240,
> > -			      21 0 1 64,
> > -			      6 0 0 65535,
> > -			      6 0 0 0"
> 
> Good to get rid of that. Also not to have get_maintainer.pl cc'ing the
> BPF ML just for that :)

Got it.

> 
> >  init_partial()
> >  {
> >  	capout=$(mktemp)
> > @@ -147,6 +110,14 @@ init_partial()
> >  		if $checksum; then
> >  			ip netns exec $netns sysctl -q net.mptcp.checksum_enabled=1
> >  		fi
> > +
> > +		ip netns exec "$netns" nft add table inet mjoin_table
> > +		ip netns exec "$netns" nft add chain inet mjoin_table input \
> > +			'{ type filter hook input priority filter; policy accept; }'
> > +		ip netns exec "$netns" nft add chain inet mjoin_table output \
> > +			'{ type filter hook output priority filter; policy accept; }'
> > +		ip netns exec "$netns" nft add chain inet mjoin_table mangle \
> > +			'{ type filter hook output priority mangle; policy accept; }'
> 
> I hope having this done by default for all subtests will not have a big
> impact at the end when using a debug kernel. Do you mind checking the
> impact, please? Just not to add a few seconds for each of the 130+
> subtest if it is only needed in some of them.

It shouldn't, I will test the running time before/after the change.

> 
> If it is, we could move that to a new helper and call it when 'nft' is
> required, it shouldn't be in many places I guess. This new helper could
> also be used to add new rules, or this could be a "reset_" helper, I
> didn't check what would be best.

I will check if this could be add as a helper.

> > +	nft_handle=$(ip netns exec "$ns2" nft -e --handle add rule \
> > +		inet mjoin_table output meta nfproto ipv${ip} \
> > +		tcp option mptcp subtype add-addr \
> 
> That's clearer, nice!
> 
> I just hope devs and CIs will use a recent enough version for nft (>=
> 1.1.2 from Apr. 25) to support mptcp subtypes. (Fine to use them, no
> need to have a fallback mechanism.)
> 
> > +		drop | head -n1 | awk '{print $NF}')
> 
> Why do you need "head -n1 | awk '{print $NF}'"? Can we not look at the
> ret code like we did with IPTables?
> 
> Same below with the RM_ADDR subtype, but for the reject ones, you do
> check the ret code.
> 
> EDIT: mmh, I see you are using "nft_handle" below, but not the one set
> here, right?. That's not very clear when it is set in the function and
> used later. Plus this field is not reset before/after each subtest. Is
> this really needed? I guess you used it for others because it is easier
> remove rules, right?
> 
> If you don't need this one (or any set in helpers), don't set it/them,
> and don't use a global variable. Or reset it in init_partial, but prefer
> using local variable with a limited scope.

Yes, we don't need the handle in other place, which I will remove them.
But for endpoint_tests(), after adding rules in reset_with_tcp_filter,
we need to remove the rule outside. I will reset it after each test.

> 
> Also, maybe clearer to use 'nft -j' with 'jq' to get that (if possible)?

I check the output of `nft -j` (paste an example at the end of mail),
which looks not each to get the rule handle easily.


> 
> One last note: for new features linked to MPTCP that might take multiple
> versions to get ready, it might be better to send these patches only to
> the MPTCP ML (no need to add anybody else in cc). Then we will apply
> them in our tree and send them to netdev when we consider them as
> "ready" (and hope for Clashiko not to get back to them days/weeks later,
> but that should be a temporally issue :) ).

Thanks for the notes. I used to rely on `b4 auto-to-cc` too much...

Regards
Hangbin

An example of `nft -j` output:
{
  "nftables": [
    {
      "metainfo": {
        "version": "1.1.6",
        "release_name": "Commodore Bullmoose #7",
        "json_schema_version": 1
      }
    },
    {
      "table": {
        "family": "ip",
        "name": "filter",
        "handle": 1
      }
    },
    {
      "chain": {
        "family": "ip",
        "table": "filter",
        "name": "OUTPUT",
        "handle": 1,
        "type": "filter",
        "hook": "output",
        "prio": 0,
        "policy": "accept"
      }
    },
    {
      "rule": {
        "family": "ip",
        "table": "filter",
        "chain": "OUTPUT",
        "handle": 2,
        "expr": [
          {
            "match": {
              "op": "==",
              "left": {
                "&": [
                  {
                    "payload": {
                      "protocol": "tcp",
                      "field": "flags"
                    }
                  },
                  {
                    "|": [
                      "fin",
                      "syn",
                      "rst",
                      "ack"
                    ]
                  }
                ]
              },
              "right": "syn"
            }
          },
          {
            "match": {
              "op": "==",
              "left": {
                "meta": {
                  "key": "mark"
                }
              },
              "right": 1
            }
          },
          {
            "counter": {
              "packets": 0,
              "bytes": 0
            }
          },
          {
            "accept": null
          }
        ]
      }
    },
    {
      "rule": {
        "family": "ip",
        "table": "filter",
        "chain": "OUTPUT",
        "handle": 3,
        "expr": [
          {
            "match": {
              "op": "==",
              "left": {
                "&": [
                  {
                    "payload": {
                      "protocol": "tcp",
                      "field": "flags"
                    }
                  },
                  "rst"
                ]
              },
              "right": "rst"
            }
          },
          {
            "match": {
              "op": "==",
              "left": {
                "meta": {
                  "key": "mark"
                }
              },
              "right": 0
            }
          },
          {
            "counter": {
              "packets": 0,
              "bytes": 0
            }
          },
          {
            "accept": null
          }
        ]
      }
    }
  ]
}

  reply	other threads:[~2026-09-03  2:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  6:52 [PATCH mptcp-next 0/2] selftests: mptcp: convert iptables to nftables Hangbin Liu
2026-09-02  6:52 ` [PATCH mptcp-next 1/2] selftests: mptcp: convert iptables to nftables for mptcp_sockopt.sh Hangbin Liu
2026-09-02  7:02   ` sashiko-bot
2026-09-02  7:47     ` Hangbin Liu
2026-09-02  9:17   ` Matthieu Baerts
2026-09-03  2:15     ` Hangbin Liu
2026-09-02  6:52 ` [PATCH mptcp-next 2/2] selftests: mptcp: convert iptables to nftables for mptcp_join.sh Hangbin Liu
2026-09-02 10:00   ` Matthieu Baerts
2026-09-03  2:02     ` Hangbin Liu [this message]
2026-09-03  6:35       ` Hangbin Liu
2026-09-03  6:54         ` Florian Westphal
2026-09-03  7:35           ` Hangbin Liu
2026-09-03  9:28       ` Matthieu Baerts
2026-09-04  8:01         ` Hangbin Liu
2026-09-04 16:40           ` Matthieu Baerts
2026-09-07  1:02             ` Hangbin Liu
2026-09-07  5:50               ` Matthieu Baerts
2026-09-07  6:59                 ` Hangbin Liu
2026-09-07  7:55                   ` Matthieu Baerts
2026-09-02  7:23 ` [PATCH mptcp-next 0/2] selftests: mptcp: convert iptables to nftables MPTCP CI
2026-09-02  8:14 ` 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=apjU-uM8dvxnVcaP@fedora \
    --to=hangbin.liu@linux.dev \
    --cc=liuhangbin@kylinos.cn \
    --cc=matttbe@kernel.org \
    --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.