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...
I have been looking at the tc_index field in the skb, and I think that this might fit our current purposes with some modifications. The extra bits we are currently looking for are actually for traffic control. We would need a marking target for tc_index in nf/ip tables and a way to save/restore it into the connmark. This would become an additional method of setting tc_index alongside dsmark, and the existing tcindex tc classifier can then be used to classify the packets. The only data structure change needed for this would be to add a u16 tc_index to the nf_conn structure, as we would still want to reduce the number of rules processed for each individual packet by restoring the mark from the connection for all but the first packet in each flow. Would this be an acceptable alternative, or is the nf_conn structure size restricted in the same way as the sk_buff?-- 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
