[MPTCP] Re: [RFC PATCH 5/6] mptcp: add ack work queue

[MPTCP] Re: [RFC PATCH 5/6] mptcp: add ack work queue

[Paolo Abeni]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Fri, 2019-11-08 at 23:09 +0100, Florian Westphal wrote:
> This is needed in the (unlikely) case that userspace is blocked in
> mptcp_sendmsg because wmem is exhausted.
> 
> In that case, only the rtx work queue will clean the rtx backlog, but it
> could take several milliseconds until it runs next, so add a dedicated
> work queue that will run as soon as possible.
> 
> We can avoid scheduling the work if the mptcp socket is writeable, next
> send/recv call will also clean acked dfrags.
> 
> An alternative approach is to add a new mptcp flag and re-use the
> existing retrans worker, let me know if this is the preferred solution.

It looks like core TCP uses both approach for timers (overloading a
timer with multiple duties, and using multiple timers for different
activities).

Since mptcp_ack_work() matches closely the initial bits of
mptcp_retransmit(), In this specific scenario I think reusing the
existing worker (plus flag) would be better.

Cheers,

Paolo

[MPTCP] Re: [RFC PATCH 5/6] mptcp: add ack work queue

[Florian Westphal]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Paolo Abeni <pabeni(a)redhat.com> wrote:
> Since mptcp_ack_work() matches closely the initial bits of
> mptcp_retransmit(), In this specific scenario I think reusing the
> existing worker (plus flag) would be better.

Done: https://git.breakpoint.cc/cgit/fw/mptcp-next.git/commit/?h=wmem_acct_05&id=fea55d959e29da51c605dad9c5e84544622d1b49

I'll resend once others had a chance to look at this series as well.

[MPTCP] Re: [RFC PATCH 5/6] mptcp: add ack work queue

[Mat Martineau]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]


On Mon, 11 Nov 2019, Florian Westphal wrote:

> Paolo Abeni <pabeni(a)redhat.com> wrote:
>> Since mptcp_ack_work() matches closely the initial bits of
>> mptcp_retransmit(), In this specific scenario I think reusing the
>> existing worker (plus flag) would be better.
>
> Done: https://git.breakpoint.cc/cgit/fw/mptcp-next.git/commit/?h=wmem_acct_05&id=fea55d959e29da51c605dad9c5e84544622d1b49
>
> I'll resend once others had a chance to look at this series as well.

I think the combined worker should be ok for DATA_FIN too (which Florian 
had mentioned sharing the ack workqueue with).

--
Mat Martineau
Intel