quoted
We have to be a bit creative/hacky to keep skb size small.
I agree. I don't think these feature deserve an skb size increase, so
some hackery is required.
Though, as skb->cb[] is somewhat 'owned' by the protocol families on
socket enqueue
I tend to find aliasing skb->priority with skb->dropcount "a lesser
evil" as compared with
partitioning the skb->cb[] space.
Please consider another field than priority. There are use
cases that want to receive priority, similar to reading mark.
Indeed, I have a draft packet auxdata patch for one user who wants
to see the iptables changes (and infer tc effects) on egress packets.
Fwiw, that patch also exposes mark, and runs into exactly this issue
that you're fixing, so thanks :)
Fields that are consistently NULL on enqueue, such as the dev field
that Eric proposed, do not have this drawback.