Thread (11 messages) flat view 11 messages, 3 authors, 2021-01-23

Re: [PATCH v2 net-next 5/5] mptcp: implement delegated actions

From: Paolo Abeni <pabeni@redhat.com>
Date: 2021-01-23 07:12:29
Also in: mptcp

On Fri, 2021-01-22 at 15:23 -0800, Jakub Kicinski wrote:
On Fri, 22 Jan 2021 09:25:07 +0100 Paolo Abeni wrote:
quoted
quoted
Do you need it because of locking?  
This infrastructure is used to avoid the workqueue usage in the MPTCP
receive path (to push pending data). With many mptcp connections
established that would be very bad for tput and latency. This
infrastructure is not strictly needed from a functinal PoV, but I was
unable to find any other way to avoid the workqueue usage.
But it is due to locking or is it not? Because you're running the
callback in the same context, so otherwise why not just call the
function directly? Can't be batching, it's after GRO so we won't 
batch much more.
Thank you for the feedback. 

Let me try to elaborate a bit more on this. When processing the input
packet (MPTCP data ack) on the MPTCP subflow A, under the subflow A
socket lock, we possibly need to push some data via a different subflow
B - depending on the MPTCP packet scheduler decision. We can't try to
acquire the B subflow socket lock due to ABBA deadlock.

Either the workqueue usage and this infra avoid the deadlock breaking
the locks chain.

Should not have any bad iteraction with threaded NAPI nor busy polling,
but I don't have experimented yet. Placing that on my TODO list.

Thanks!

Paolo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help