lkml.org 
[lkml]   [2008]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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.


    \
     
     \ /
      Last update: 2008-07-22 14:51    [W:0.023 / U:29.504 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site