lkml.org 
[lkml]   [2009]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: seeing strange values for tcp sk_rmem_alloc
    Chris Friesen a écrit :
    > I'm hoping someone might be able to explain some odd behaviour that I'm
    > seeing.
    >
    > Some of our developers wanted to be able to see how much of their rx
    > socket buffer space was in use, so I added the following to sock_ioctl()
    >
    >
    > case SIOCGSKRMEMALLOC:
    > {
    > int tmp;
    > err = -EINVAL;
    > if(!sock->sk)
    > break;
    > tmp = atomic_read(&sock->sk->sk_rmem_alloc);
    > err = copy_to_user(argp, &tmp, sizeof(tmp));
    > break;
    > }
    >
    > To validate it, I wrote a testcase that opened a tcp socket, then looped
    > sending 2k of data at a time to it and calling the above ioctl to check
    > the sk_rmem_alloc value (without ever reading from the socket).
    >
    > The results were odd--I've copied them below. Can anyone explain how I
    > can send 20K of data but sk_rmem_alloc still only shows 4.8K used, then
    > it suddenly jumps by a lot on the next packet to something that more
    > reflects reality, then repeats that pattern again? Is there some
    > additional buffering happening somewhere in the TCP stack?
    >

    Me wondering why you think sk_rmem_alloc is about TX side.

    Its used in RX path. rmem means ReadMemory.

    You can send 1 Gbytes of data, and sk_rmem_alloc doesnt change, if your
    TCP stream is unidirectionnal.

    sk_rmem_alloc grows when skb are queued into receive queue
    sk_rmem_alloc shrinks when application reads this receive queue.




    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-12-01 18:01    [W:0.086 / U:0.276 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site