[MPTCP] Re: [PATCH v2 0/2] mptcp: add primitive scheduler

[MPTCP] Re: [PATCH v2 0/2] mptcp: add primitive scheduler

[Mat Martineau]

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


On Wed, 30 Oct 2019, Florian Westphal wrote:

> This is a simplified version of a sendmsg ssk selection strategy,
> so sendmsg or retransmit could also occur on a backup subflow.
>
> In the initial submission it was pointed out that we should not
> send more data when a retransmission is happening.
>

I think I had a concern about starving the retransmit worker if userspace 
kept sending data, but on further thought it seems like the retransmit 
worker will get a chance to send eventually. Once the non-retransmit path 
in mptcp_sendmsg_frag() has to wait for memory due to unacked MPTCP-level 
data, the ssk transmit queue will empty out and retransmission will 
proceed.

While waiting for the queue to be completely empty at retransmit timeout 
time may lead to idling the link, it should not get permanently stuck, 
right? Or does the MPTCP-level accounting not work that way yet (given 
what you're planning with wmem_queued accounting)?

> As this isn't directly related to this I've decided to send those two
> patches now and work on sendmsg moderation next.
>
> The plan is to add wmem_queued accounting to the mptcp socket and
> then make sendmsg/mptcp_poll consider mptcp socket wmem limits to
> avoid sending more data if there are no mptcp-level acknowledgements.
>
> This however might take some time because msk->ack_seq update occurs only
> at recvmsg time and not during mptcp ack processing.
> For this to work properly, mptcp-level ack update should not depend on
> a recvmsg call.
>

This sounds like a good plan.

--
Mat Martineau
Intel

[MPTCP] Re: [PATCH v2 0/2] mptcp: add primitive scheduler

[Mat Martineau]

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


On Wed, 30 Oct 2019, Mat Martineau wrote:

>
> On Wed, 30 Oct 2019, Florian Westphal wrote:
>
>> This is a simplified version of a sendmsg ssk selection strategy,
>> so sendmsg or retransmit could also occur on a backup subflow.
>> 
>> In the initial submission it was pointed out that we should not
>> send more data when a retransmission is happening.
>> 
>
> I think I had a concern about starving the retransmit worker if userspace 
> kept sending data, but on further thought it seems like the retransmit worker 
> will get a chance to send eventually. Once the non-retransmit path in 
> mptcp_sendmsg_frag() has to wait for memory due to unacked MPTCP-level data, 
> the ssk transmit queue will empty out and retransmission will proceed.
>
> While waiting for the queue to be completely empty at retransmit timeout time 
> may lead to idling the link, it should not get permanently stuck, right? Or 
> does the MPTCP-level accounting not work that way yet (given what you're 
> planning with wmem_queued accounting)?

To answer my own question: I should have taken a closer look at 
mptcp_sendmsg_frag before hitting 'send', it does look like we aren't 
doing that kind of MPTCP-level accounting yet. We might end up using a lot 
of memory if userspace keeps sending.

>
>> As this isn't directly related to this I've decided to send those two
>> patches now and work on sendmsg moderation next.
>> 
>> The plan is to add wmem_queued accounting to the mptcp socket and
>> then make sendmsg/mptcp_poll consider mptcp socket wmem limits to
>> avoid sending more data if there are no mptcp-level acknowledgements.
>> 
>> This however might take some time because msk->ack_seq update occurs only
>> at recvmsg time and not during mptcp ack processing.
>> For this to work properly, mptcp-level ack update should not depend on
>> a recvmsg call.
>> 
>
> This sounds like a good plan.
>

--
Mat Martineau
Intel

[MPTCP] Re: [PATCH v2 0/2] mptcp: add primitive scheduler

[Florian Westphal]

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

Mat Martineau <mathew.j.martineau(a)linux.intel.com> wrote:
> To answer my own question: I should have taken a closer look at
> mptcp_sendmsg_frag before hitting 'send', it does look like we aren't doing
> that kind of MPTCP-level accounting yet. We might end up using a lot of
> memory if userspace keeps sending.

Yes, working on it.