Messages in this thread |  | | | Date | Tue, 22 Jul 2008 14:48:42 +0200 | | From | Patrick McHardy <> | | Subject | Re: [PATCH] Traffic control cgroups subsystem |
| |
Paul Menage wrote: > On Tue, Jul 22, 2008 at 6:35 AM, Patrick McHardy <kaber@trash.net> 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.
|  |