Add MPTCP support with the --multipath flag

[marcosfsch]

• Version of iperf3 (or development branch, such as master or
  3.1-STABLE) to which this pull request applies:
  master

• Issues fixed (if any):
  Rebase of PR #1166, including testing for MPTCP support.

• Brief description of code changes (suitable for use as a commit message):
  Recent version of the Linux kernel (5.9) gained MPTCP support, this change
  allows easy testing such protocol.
  MPTCP is strongly tied to TCP, and the kernel APIs are almost the same,
  so this change does not implement a new 'struct protocol'. Instead it just
  extend the TCP support to optionally enable multipath via the --multipath or
  -m switch.

The only required dependency is the 'IPPROTO_MPTCP' protocol number
definition, which should be provided by the netinet/in.h header.
To keep things simple, just conditionally provide the required
protocol, if the system header does not have it yet.

[matttbe]

@marcosfsch thank you for this rebase. @geliangtang did another one in #1661 with some small modifications discussed with the MPTCP devs:

• no build check: better to check at run-time, the kernel could be different
• --mptcp (shorter) instead of --multipath (too vague, could be multipath QUIC, etc.)
• place the new proto arg after type in the modified function signatures.

Are the modifications OK for you? Would it be OK to close this PR?
Hopefully IPerf3 devs will be able to review #1661 soon :)

[marcosfsch]

I'm ok with closing this PR, thanks for the rebase and improvements. Em qua., 19 de jun. de 2024 05:16, Matthieu Baerts ***@***.***> escreveu:

…

@marcosfsch <https://github.com/marcosfsch> thank you for this rebase. @geliangtang <https://github.com/geliangtang> did another one in #1661 <#1661> with some small modifications discussed with the MPTCP devs: - no build check: better to check at run-time, the kernel could be different - --mptcp (shorter) instead of --multipath (too vague, could be multipath QUIC, etc.) - place the new proto arg after type in the modified function signatures. Are the modifications OK for you? Would it be OK to close this PR? Hopefully IPerf3 devs will be able to review #1661 <#1661> soon :) — Reply to this email directly, view it on GitHub <#1615 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKU4YSL6DJSAHWOVHICMAL3ZIE47DAVCNFSM6AAAAABAISIZXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYGA2TCOJYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>