diff options
| author | Jakub Kicinski <kuba@kernel.org> | 2026-05-11 18:01:39 -0700 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-05-11 18:01:39 -0700 |
| commit | 6d596975c18ae284e3e3fabdff9b434cabfbd57a (patch) | |
| tree | 2c1bd91e512531c3343224a01b39713a521eb8df /rust/kernel/alloc/kvec/errors.rs | |
| parent | cb880b02117de1040b0e23a79d9c05d9a6c475b7 (diff) | |
| parent | ed5372634c5b936163d0760cc44599f6797b7236 (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 'rust/kernel/alloc/kvec/errors.rs')
0 files changed, 0 insertions, 0 deletions
