summaryrefslogtreecommitdiff
path: root/scripts/const_structs.checkpatch
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2026-05-11 18:01:39 -0700
committerJakub Kicinski <kuba@kernel.org>2026-05-11 18:01:39 -0700
commit6d596975c18ae284e3e3fabdff9b434cabfbd57a (patch)
tree2c1bd91e512531c3343224a01b39713a521eb8df /scripts/const_structs.checkpatch
parentcb880b02117de1040b0e23a79d9c05d9a6c475b7 (diff)
parented5372634c5b936163d0760cc44599f6797b7236 (diff)
Merge branch 'mptcp-pm-in-kernel-increase-limits'
Matthieu Baerts says: ==================== mptcp: pm: in-kernel: increase limits Allow switching from 8 to 64 for the maximum number of subflows and accepted ADD_ADDR, and from 8 to 255 for the number of MPTCP endpoints. The previous limit of 8 subflows makes sense in most cases. Using more subflows will very likely *not* improve the situation, and could even decrease the performances. But there are no technical limitations nor performance impact to raise this limit, so let's do it: this will allow people with very specific use-cases, and researchers to easily create more subflows, and measure the performance impact by themselves. - Patches 1-2: increase subflows and accepted ADD_ADDR limits. - Patches 3-4: increase endpoints limit. - Patches 5-7: validate the new limits: 64 subflows, 255 endpoints. - Patch 8: selftests: use send()/recv() instead of sendto()/recvfrom(). ==================== Link: https://patch.msgid.link/20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'scripts/const_structs.checkpatch')
0 files changed, 0 insertions, 0 deletions