Skip to content

I
iproute2
Switch branch/tag
  1. 18 Feb, 2016 8 commits
  3. 09 Feb, 2016 24 commits
  5. 07 Feb, 2016 5 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
    • Daniel Borkmann's avatar
      tc, bpf: improve verifier logging · f31645d1
      Daniel Borkmann authored 
      With a bit larger, branchy eBPF programs f.e. already ~BPF_MAXINSNS/7 in
size, it happens rather quickly that bpf(2) rejects also valid programs
when only the verifier log buffer size we have in tc is too small.

Change that, so by default we don't do any logging, and only in error
case we retry with logging enabled. If we should fail providing a
reasonable dump of the verifier analysis, retry few times with a larger
log buffer so that we can at least give the user a chance to debug the
program.
Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      f31645d1
    • Daniel Borkmann's avatar
      tc, bpf, examples: further bpf_api improvements · 92a36995
      Daniel Borkmann authored 
      Add a couple of improvements to tc's BPF api, that facilitate program
development.
Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      92a36995
  7. 05 Feb, 2016 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7