Re: [RFC PATCH mptcp-next v2 5/8] mptcp: setsockopt: add SO_MARK support

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

On Thu, 25 Mar 2021, Florian Westphal wrote:

> Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:
>> On Wed, 24 Mar 2021, Florian Westphal wrote:
>>
>>> Value is synced to all subflows.
>>>
>>
>> The use case I remember for SO_MARK with MPTCP was to designate different
>> interfaces for different subflows:
>>
>> https://lore.kernel.org/mptcp/CAKD1Yr2sBCdUO48cp=rZQ6s4v13ytpPd9oPT+U=iYrdXtba5HA@mail.gmail.com/
>>
>>
>> Once we have a way to set individual subflow options, it could both be
>> useful to set sk_mark on all subflows, and also to not override individual
>> settings. The current sync mechanism would overwrite all supported options
>> when any single option changes.
>>
>> There's no way for these options to diverge yet, so we could wait on solving
>> that problem. Do you think it's better to stick with the current syncing
>> method for now, or to do more detailed tracking of which options need to be
>> synced?
>
> Looks like same issue as with TCP_CONGESTION.
> Q is how we can expose the individual subflows.
>
> I see
> https://tools.ietf.org/html/draft-hesmans-mptcp-socket-03
>
> Should that be implemented instead of this?
>

I had a chance to look at the linked draft, and I think where we ended up 
in the discussion earlier today was this:

  * per-subflow options are useful (SO_MASK, etc)

  * overall settings like this patch set does are also helpful, I think 
especially to make MPTCP sockets behave more like TCP sockets.


The two should be compatible, and the concern I'm pointing out is that the 
proposed sync would clobber individual subflow options even if the 
matching MPTCP-level sockopts had never been set. That may be addressible 
by only syncing "new" subflows rather than all of them in the list.

--
Mat Martineau
Intel