1. 23 Mar, 2015 16 commits
  2. 21 Mar, 2015 20 commits
  3. 20 Mar, 2015 4 commits
    • David S. Miller's avatar
      Merge branch 'ebpf-next' · f6877fcf
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      This set adds native eBPF support also to act_bpf and thus covers tc
      with eBPF in the classifier *and* action part.
      
      A link to iproute2 preview has been provided in patch 2 and the code
      will be pushed out after Stephen has processed the classifier part
      and helper bits for tc.
      
      This set depends on ced585c8 ("act_bpf: allow non-default TC_ACT
      opcodes as BPF exec outcome"), so a net into net-next merge would be
      required first. Hope that's fine by you, Dave. ;)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6877fcf
    • Daniel Borkmann's avatar
      act_bpf: add initial eBPF support for actions · a8cb5f55
      Daniel Borkmann authored
      This work extends the "classic" BPF programmable tc action by extending
      its scope also to native eBPF code!
      
      Together with commit e2e9b654 ("cls_bpf: add initial eBPF support
      for programmable classifiers") this adds the facility to implement fully
      flexible classifier and actions for tc that can be implemented in a C
      subset in user space, "safely" loaded into the kernel, and being run in
      native speed when JITed.
      
      Also, since eBPF maps can be shared between eBPF programs, it offers the
      possibility that cls_bpf and act_bpf can share data 1) between themselves
      and 2) between user space applications. That means that, f.e. customized
      runtime statistics can be collected in user space, but also more importantly
      classifier and action behaviour could be altered based on map input from
      the user space application.
      
      For the remaining details on the workflow and integration, see the cls_bpf
      commit e2e9b654. Preliminary iproute2 part can be found under [1].
      
        [1] http://git.breakpoint.cc/cgit/dborkman/iproute2.git/log/?h=ebpf-actSigned-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8cb5f55
    • Daniel Borkmann's avatar
      ebpf: add sched_act_type and map it to sk_filter's verifier ops · 94caee8c
      Daniel Borkmann authored
      In order to prepare eBPF support for tc action, we need to add
      sched_act_type, so that the eBPF verifier is aware of what helper
      function act_bpf may use, that it can load skb data and read out
      currently available skb fields.
      
      This is bascially analogous to 96be4325 ("ebpf: add sched_cls_type
      and map it to sk_filter's verifier ops").
      
      BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT need to be
      separate since both will have a different set of functionality in
      future (classifier vs action), thus we won't run into ABI troubles
      when the point in time comes to diverge functionality from the
      classifier.
      
      The future plan for act_bpf would be that it will be able to write
      into skb->data and alter selected fields mirrored in struct __sk_buff.
      
      For an initial support, it's sufficient to map it to sk_filter_ops.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Reviewed-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94caee8c
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 0fa74a4b
      David S. Miller authored
      Conflicts:
      	drivers/net/ethernet/emulex/benet/be_main.c
      	net/core/sysctl_net_core.c
      	net/ipv4/inet_diag.c
      
      The be_main.c conflict resolution was really tricky.  The conflict
      hunks generated by GIT were very unhelpful, to say the least.  It
      split functions in half and moved them around, when the real actual
      conflict only existed solely inside of one function, that being
      be_map_pci_bars().
      
      So instead, to resolve this, I checked out be_main.c from the top
      of net-next, then I applied the be_main.c changes from 'net' since
      the last time I merged.  And this worked beautifully.
      
      The inet_diag.c and sysctl_net_core.c conflicts were simple
      overlapping changes, and were easily to resolve.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fa74a4b