From: Luuk Paulussen <redacted>
Date: Tue, 1 Dec 2015 00:12:24 +0000

On 11/30/2015 05:49 PM, David Miller wrote:

quoted

From: Luuk Paulussen <redacted>
Date: Mon, 30 Nov 2015 04:10:43 +0000

quoted

On 11/30/2015 02:58 PM, David Miller wrote:

quoted

If you guys, really anyone, can find a way to remove some other 32-bit
item from sk_buff, you can expand skb->mark to 64-bits. But otherwise,
I'm going to be strongly against it. sk_buff is already enormous and
larger than it should be. So I'm going to resist any change that makes
it even larger. Thanks.

Would the level of objection be the same if this was done as an
"extended mark" field under a configurable off-by-default option?

Every distribtion will turn the option on.

Config options hiding "cost" is never an argument to bloat
a critical core datstructure up, sorry.

Fair enough, although if most distributions would turn it on, it does 
suggest that it is interesting...

Lots of things are interesting and useful to many people.

Even the most useful feature I would balk at it's implementation
if it bloated up sk_buff.  Period.

You don't understand what the core issue is, which is sk_buff size
which has an effect on all users.