summaryrefslogtreecommitdiffstats
path: root/include/net/bluetooth
diff options
context:
space:
mode:
authorDaniel Borkmann <daniel@iogearbox.net>2015-08-31 15:58:47 +0200
committerDavid S. Miller <davem@davemloft.net>2015-08-31 12:34:00 -0700
commitc3a8d9474684d391b0afc3970d9b249add15ec07 (patch)
treef12130b61955f4471ebd61474244ecf9ebdc0858 /include/net/bluetooth
parentb8d3e4163a3562d7cba486687904383e78e7dd6a (diff)
downloadlinux-c3a8d9474684d391b0afc3970d9b249add15ec07.tar.bz2
tcp: use dctcp if enabled on the route to the initiator
Currently, the following case doesn't use DCTCP, even if it should: A responder has f.e. Cubic as system wide default, but for a specific route to the initiating host, DCTCP is being set in RTAX_CC_ALGO. The initiating host then uses DCTCP as congestion control, but since the initiator sets ECT(0), tcp_ecn_create_request() doesn't set ecn_ok, and we have to fall back to Reno after 3WHS completes. We were thinking on how to solve this in a minimal, non-intrusive way without bloating tcp_ecn_create_request() needlessly: lets cache the CA ecn option flag in RTAX_FEATURES. In other words, when ECT(0) is set on the SYN packet, set ecn_ok=1 iff route RTAX_FEATURES contains the unexposed (internal-only) DST_FEATURE_ECN_CA. This allows to only do a single metric feature lookup inside tcp_ecn_create_request(). Joint work with Florian Westphal. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/net/bluetooth')
0 files changed, 0 insertions, 0 deletions