Hello, Currently we have a number of router features (firewall, QoS, etc) making use of ip tables and connection tracking. We do this by giving each feature a certain area of skb->mark (say 8 bits each). This allows us to simply restore skb->mark (using connection tracking) for packets in a flow using the logic below.
Our software logic is: 1. The first packet in a flow traverses through ip-tables where each feature has set rules to mark their section of skb->mark. 2. We then store the mark into connmark. 3. Then as each packet in the flow hits ip tables the first rule in ip-tables simply restores the connmark and the packet goes to egress. Up until now this has worked very well for us. However since skb->mark is only 32 bits we have quickly run out of bits for marking. This leaves us with two options: - Don't allow all features to be enabled at once (i.e. multiple features share the same area of skb->mark). This is not ideal. - Increase the size of skb->mark (or another solution such as adding an additional field into sk_buff for marking). Hopefully what I have explained above is a strong example of where skb->mark is no longer large enough on routers using connection tracking to achieve superior performance. I'm emailing this list for feedback on the feasibility of increasing skb->mark or adding a new field for marking. Perhaps this extension could be done under a new CONFIG option. Perhaps there are other ways we could achieve the desired behaviour? Thanks, Matt
