Re: [PATCH v2 mptcp-next 1/8] mptcp: enable busypoll from mptcp receive path

[Paolo Abeni <pabeni@redhat.com>]

On Fri, 2021-05-14 at 12:35 +0200, Paolo Abeni wrote:
> We will have a N:1 mapping (where N is the number of subflows using the
> code above and could be "optimized" to the number of different napi_id
> in use by such subflows with the changes discussed in the last part of
> my previous email).
> 
> But still should not introuce additional latency. If e.g. we are
> polling on napi_id_1 and packets arrive on napi id_2, since the msk
> socket lock is not held, the rx subflow input path will deliver them to
> the msk receive queue and the:
> 
> 	'if (skb_queue_empty_lockless(&sk->sk_receive_queue))'
> 
> check will terminate the loop as soon as polling no napi_id_1
> completes.
> 
> Well, that could actually introduce some latency, e.g. if napi_id_1 is
> under heavy traffic sent from some different peer. Not 110% sure
> anyway: BP reduce lantency mostly by avoiding tripping on the process
> scheduler, and we will get that part right.
> 
> Assuming this later consideration is correct, we could eventually
> consider always doing busy polling on a single napi instance (belonging
> to an active, non backup subflow) even in presence of multiple active
> subflows, and that should still reduce latency.

If I read correctly, this is roughly the approach used by mptcp.org
> 
> I guess a little experimentation will help ;) 

@Christoph, do you have info/paper/data for BP && mptcp && multiple
napi ids? Or (half-seriously) some university PHD willing do some
academic research on it? ;)))

/P