lkml.org 
[lkml]   [2014]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v7 net-next 1/3] filter: add Extended BPF interpreter and converter
    From
    On Sun, Mar 9, 2014 at 7:45 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
    > On Sat, 2014-03-08 at 15:15 -0800, Alexei Starovoitov wrote:
    >
    >> +/**
    >> + * sk_run_filter_ext - run an extended filter
    >> + * @ctx: buffer to run the filter on
    >> + * @insn: filter to apply
    >> + *
    >> + * Decode and execute extended BPF instructions.
    >> + * @ctx is the data we are operating on.
    >> + * @filter is the array of filter instructions.
    >> + */
    >> +notrace u32 sk_run_filter_ext(void *ctx, const struct sock_filter_ext *insn)
    >> +{
    >> + u64 stack[64];
    >> + u64 regs[16];
    >> + void *ptr;
    >> + u64 tmp;
    >> + int off;

    First of all, great that you finally reviewed it! Feedback is appreciated :)

    > Why is this 'notrace' ?

    to avoid overhead of dummy call.
    JITed filters are not adding this dummy call.
    So 'notrace' on interpreter brings it to parity with JITed filters.

    > 80 u64 on the stack, that is 640 bytes to run a filter ????

    yes. that was described in commit log and in Doc...filter.txt:
    "
    - 16 4-byte stack slots for register spill-fill replaced with
    up to 512 bytes of multi-use stack space
    "

    For interpreter it is prohibitive to dynamically allocate stack space
    that's why it just grabs 64*8 to run any program.
    For JIT it's going to be close to zero for majority of filters, since
    generated program will allocate only as much as was allowed
    by sk_chk_filter_ext(). Only largest programs would need 'up to 512'.
    This much stack would be needed for programs that need to use
    large key/value pairs in their ebpf tables.
    So far I haven't seen a program that approaches this limit,
    but it seems to me that 512 is reasonable, since kernel warns on
    functions with > 1k stack.

    btw, current x86 jit just does 'subq $96,%rsp',
    I think ebpf jit should use the minimum amount of stack. Only amount
    that is needed.
    May be I'm over thinking it and having 'subq $512, %rsp' for JIT is also fine.
    Let me know.

    Thanks
    Alexei


    \
     
     \ /
      Last update: 2014-03-09 19:01    [W:3.516 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site