From: Luuk Paulussen <luuk.paulus...@alliedtelesis.co.nz> Date: Tue, 1 Dec 2015 00:12:24 +0000
> On 11/30/2015 05:49 PM, David Miller wrote: >> From: Luuk Paulussen <luuk.paulus...@alliedtelesis.co.nz> >> Date: Mon, 30 Nov 2015 04:10:43 +0000 >> >>> On 11/30/2015 02:58 PM, David Miller wrote: >>>> 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
