1. 02 Mar, 2016 3 commits
  2. 21 Feb, 2016 2 commits
  3. 18 Feb, 2016 8 commits
  4. 09 Feb, 2016 24 commits
  5. 07 Feb, 2016 3 commits
    • Roopa Prabhu's avatar
      bridge: support for static fdb entries · a1987cd1
      Roopa Prabhu authored
      There is no intuitive option to add static fdb entries today.
      'temp' seems to have a side effect of adding
      'static' fdb entries. But the name and intent
      of 'temp' does not say anything about it being static.
      
      example:
      bridge fdb add operates as follows:
      
      $bridge fdb add 00:01:02:03:04:05 dev eth0 master
      $bridge fdb add 00:01:02:03:04:06 dev eth0 master temp
      $bridge fdb add 00:01:02:03:04:07 dev eth0 master local
      
      $bridge fdb show
      00:01:02:03:04:05 dev eth0 permanent
      00:01:02:03:04:06 dev eth0 static
      00:01:02:03:04:07 dev eth0 permanent
      00:01:02:03:04:08 dev eth0 <<== dynamic, ageable learned mac
      
      This patch adds a new bridge fdb type 'static' which
      makes sure NUD_NOARP and NUD_REACHABLE is set for static
      entries. This effectively is nothing but what 'temp'
      does today. But the name 'temp' is misleading.
      
      After the patch:
      $bridge fdb add 00:01:02:03:04:06 dev eth0 master static
      
      $bridge fdb show
      00:01:02:03:04:06 dev eth0 static
      
      'temp' could ideally be a dynamic mac that can age (ie just
      NUD_REACHABLE). But, 'temp' sets 'NUD_NOARP' and 'NUD_REACHABLE'.
      Too late to change 'temp' now. But, we are thinking of introduing a
      'dynamic' keyword after this patch that only sets NUD_REACHABLE.
      Signed-off-by: default avatarWilson Kok <wkok@cumulusnetworks.com>
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      a1987cd1
    • Daniel Borkmann's avatar
      tc, bpf: use bind/type macros from gelf · 5230a2ed
      Daniel Borkmann authored
      Don't reimplement them and rather use the macros from the gelf header,
      that is, GELF_ST_BIND()/GELF_ST_TYPE().
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      5230a2ed
    • Daniel Borkmann's avatar
      tc, bpf: give some more hints wrt false relos · a576c6b9
      Daniel Borkmann authored
      Provide some more hints to the user/developer when relos have been found
      that don't point to ld64 imm instruction. Ran couple of times into relos
      generated by clang [1], where the compiler tried to uninline inlined
      functions with eBPF and emitted BPF_JMP | BPF_CALL opcodes. If this seems
      the case, give a hint that the user should do a work-around to use
      always_inline annotation.
      
        [1] https://llvm.org/bugs/show_bug.cgi?id=26243#c3Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      a576c6b9