From: Florian Westphal <f...@strlen.de> Date: Mon, 26 Nov 2018 12:38:54 +0100
> This adds an extension infrastructure for sk_buff instead: > 1. extension memory is released when the sk_buff is free'd. > 2. data is shared after cloning an skb. > 3. adding extension to an skb will COW the extension > buffer if needed. So MP-TCP, when enabled for a connection, will have a new atomic operation for every packet? And new tests all in the fast paths of the networking to facilitate this feature, a cost paid by everyone. Sorry, that doesn't seem like a good idea to me. Can't they just encode whatever huge amount of crap they want to put into the CB by deriving the information from skb->sk and some tiny value like an index or something to resolve the path? In the future please document what is so enormous and absolutely required that they must put it all into the SKB control block. Like Eric, I am concerned about the slow creep of overhead. Lots of small "not that bad" additions of extra cycles here and there over time adds up to impossible to fix performance regressions. I'm sorry if this is a major disappointment for the MP-TCP folks but a better way needs to be found to integrate what they want to do with real zero cost for the rest of the world which won't be using MP-TCP and therefore should not be paying for it's added overhead at all.
