Eric Dumazet <eric.duma...@gmail.com> wrote:
> > If its going to be used as I expect, then the extension could be
> > discarded after the DSS mapping has been written to the tcp option
> > space, i.e. before cloning occurs.
>
> I do not see how this would work, without also discarding on the master skb
> the needed info.
Ok, so lets assume this would result in one atomic_inc/dec due to clone
for now for skbs coming from mptcp socket.
But I don't see why this would have to be.
> > For TCP, thats true. But there are other places that could clone, e.g.
> > when bridge has to flood-forward.
> >
>
> So you propose a mechanism that forces a preserve on clone, base on existing
> needs
> for bridging.
secpath does the same thing:
static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
{
...
#ifdef CONFIG_XFRM
new->sp = secpath_get(old->sp);
#endif
...
So I am not proposing anything new.
> > At least in bridge case the 'preseve on clone' is needed, else required
> > information is missing from the cloned skb.
> >
>
> We need something where MPTCP info does not need to be propagated all the way
> to the NIC...
Thats whats done in the MPTCP out-of-tree implementation, but I don't
think its needed.
It could just delete the extension before ->queue_xmit() AFAIU.
> This skb extension is an incentive for adding more sticky things in the skbs
> to violate layering of networking stacks :/
8-(
Where do you see "layering violations"?
