-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fallback rx path is broken #200
Labels
Comments
If the maintainers won't accept one more |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jun 17, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: multipath-tcp/mptcp_net-next#200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
matttbe
pushed a commit
that referenced
this issue
Jun 24, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 25, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
matttbe
pushed a commit
that referenced
this issue
Jun 25, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 26, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
matttbe
pushed a commit
that referenced
this issue
Jun 28, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 29, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 30, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jun 30, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when an MPTCP socket falls back to TCP, it can hit the TCP receive fast-path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: multipath-tcp/mptcp_net-next#200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
jenkins-tessares
pushed a commit
that referenced
this issue
Jul 1, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jul 1, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when an MPTCP socket falls back to TCP, it can hit the TCP receive fast-path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: multipath-tcp/mptcp_net-next#200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
jenkins-tessares
pushed a commit
that referenced
this issue
Jul 2, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
matttbe
pushed a commit
that referenced
this issue
Jul 7, 2021
The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when and MPTCP socket falls back to TCP, we can the receive fast path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: #200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Whissi
pushed a commit
to Whissi/linux-stable
that referenced
this issue
Jul 25, 2021
commit 71158bb upstream. The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when an MPTCP socket falls back to TCP, it can hit the TCP receive fast-path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: multipath-tcp/mptcp_net-next#200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Whissi
pushed a commit
to Whissi/linux-stable
that referenced
this issue
Jul 25, 2021
commit 71158bb upstream. The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when an MPTCP socket falls back to TCP, it can hit the TCP receive fast-path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: multipath-tcp/mptcp_net-next#200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
starnight
pushed a commit
to endlessm/linux
that referenced
this issue
Sep 14, 2021
BugLink: https://bugs.launchpad.net/bugs/1940139 commit 71158bb upstream. The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when an MPTCP socket falls back to TCP, it can hit the TCP receive fast-path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: multipath-tcp/mptcp_net-next#200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
it-is-a-robot
pushed a commit
to openeuler-mirror/kernel
that referenced
this issue
Oct 15, 2021
stable inclusion from stable-5.10.53 commit ea66fcb296058e0d41afa770f6900b335f8738a5 bugzilla: 175574 https://gitee.com/openeuler/kernel/issues/I4DTUX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ea66fcb296058e0d41afa770f6900b335f8738a5 -------------------------------- commit 71158bb upstream. The MPTCP receive path is hooked only into the TCP slow-path. The DSS presence allows plain MPTCP traffic to hit that consistently. Since commit e1ff9e8 ("net: mptcp: improve fallback to TCP"), when an MPTCP socket falls back to TCP, it can hit the TCP receive fast-path, and delay or stop triggering the event notification. Address the issue explicitly disabling the header prediction for MPTCP sockets. Closes: multipath-tcp/mptcp_net-next#200 Fixes: e1ff9e8 ("net: mptcp: improve fallback to TCP") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Chen Jun <chenjun102@huawei.com> Acked-by: Weilong Chen <chenweilong@huawei.com> Signed-off-by: Chen Jun <chenjun102@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
jenkins-tessares
pushed a commit
that referenced
this issue
Aug 11, 2023
BPF CI has reported the following failure: Error: #200/79 sockmap_listen/sockmap VSOCK test_vsock_redir Error: #200/79 sockmap_listen/sockmap VSOCK test_vsock_redir ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: ingress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1506: egress: write: Transport endpoint is not connected vsock_unix_redir_connectible:FAIL:1506 ./test_progs:vsock_unix_redir_connectible:1514: ingress: recv() err, errno=11 vsock_unix_redir_connectible:FAIL:1514 ./test_progs:vsock_unix_redir_connectible:1518: ingress: vsock socket map failed, a != b vsock_unix_redir_connectible:FAIL:1518 ./test_progs:vsock_unix_redir_connectible:1525: ingress: want pass count 1, have 0 It’s because the recv(... MSG_DONTWAIT) syscall in the test case is called before the queued work sk_psock_backlog() in the kernel finishes executing. So the data to be read is still queued in psock->ingress_skb and cannot be read by the user program. Therefore, the non-blocking recv() reads nothing and reports an EAGAIN error. So replace recv(... MSG_DONTWAIT) with xrecv_nonblock(), which calls select() to wait for data to be readable or timeout before calls recv(). Fixes: d61bd8c ("selftests/bpf: add a test case for vsock sockmap") Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20230804073740.194770-4-xukuohai@huaweicloud.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ok, it's almost as drastic as it sounds:
In fallback mode, tcp_rcv_established() we hit the fastpath/header prediction. Incoming data is usually enqueued via direct call to tcp_queue_rcv() and the mptcp_incoming_options() hook in tcp_data_queue() is usually not reached.
As a result, we could end-up delaying the writer wake-up or even stalling it completely.
That is somewhat perceivable even with self-tests: sometimes fallback self-tests are considerably slower than non fallback one.
Possible solutions:
The text was updated successfully, but these errors were encountered: