[MPTCP] Re: [PATCH v2 1/6] mptcp: separate accouting for wmem forward alloc mem

[Florian Westphal <fw at strlen.de>]

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

Paolo Abeni <pabeni(a)redhat.com> wrote:
> As mentioned before, one possible follow-up to this series is open-code 
> a MPTCP-specific variant of lock_sock()/release_sock() which will allow
> performing some additional/MPTCP specific actions under the msk level
> spinlock.
> 
> Specifically:
> 
> - in recevmsg(), in lock_sock(), splice sk->sk_receive_queue in msk-
> >receive_queue
> - still in recvmsg(), in release_sock(), update the bulk freed rmem 
> 
> Overall this 2 will allow acquiring no additional spinlock at all in
> the average case for recvmsg()
> 
> - in sendmsg(), in lock_sock(), move as much memory as needed from
> sk_forward_memory to wforward_memory, eventually allocating it.
> - in sendmsg(), in release_sock(), move again the unused
> wforward_memory to sk_forward_memory.
> 
> Overall this 2 will allow acquiring no additional spinlock at all in
> the average case for sendmsg() and will avoid artifacts due to the
> sk_forward_memory/wforward_memory separation.
> 
> But they additionally will allow replacing the wforward_memory field
> with a local variable. 
> 
> So I'm wondering if I should already code the above, to avoid
> introducing this additional new msk field just to remove it in a few
> patches !?!

Tricky.  Do you have hunch of how much additional code churn that
means?

If its not too much 'rewrite', I would prefer to do it later on
even if that means axing the newly added field.

If it means to rewrite most of this again then its probably
better to do it right away.