Re: [PATCH] Traffic control cgroups subsystem

From: Patrick McHardy
Date: Tue Jul 22 2008 - 08:49:01 EST

Paul Menage wrote:
On Tue, Jul 22, 2008 at 6:35 AM, Patrick McHardy <kaber@xxxxxxxxx> wrote:
Does this really have to be a new skb member? You could
simply use skb->sk->sk_cgroup_classid directly, or if
that doesn't work, maybe skb->priority.

We were actually using skb->priority in our internal version of this
patch. I suggested that the separate cgroup_classid field be added
since it might be considered an abuse of skb->priority and would
interfere with existing users of that. If that's not an issue then
reusing skb->priority is certainly possible.

Using skb->priority for classification would be fine, but it would
probably interfere with the default initialization to sk->sk_priority.

Regarding skb->sk->sk_cgroup_classid, is it always the case that the
original sk is still available when we're making traffic control
decisions? I'd thought that there were cases (e.g. cloning skbs in the
TCP retransmit path) where the pointer to the original sk is lost.

After cloning, TCP sets the owner of the skb to the socket, so
that should work fine.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at