1. 01 Jun, 2020 40 commits
    • Daniel Borkmann's avatar
      Merge branch 'bpf-ring-buffer' · e255d327
      Daniel Borkmann authored
      Andrii Nakryiko says:
      
      ====================
      Implement a new BPF ring buffer, as presented at BPF virtual conference ([0]).
      It presents an alternative to perf buffer, following its semantics closely,
      but allowing sharing same instance of ring buffer across multiple CPUs
      efficiently.
      
      Most patches have extensive commentary explaining various aspects, so I'll
      keep cover letter short. Overall structure of the patch set:
      - patch #1 adds BPF ring buffer implementation to kernel and necessary
        verifier support;
      - patch #2 adds libbpf consumer implementation for BPF ringbuf;
      - patch #3 adds selftest, both for single BPF ring buf use case, as well as
        using it with array/hash of maps;
      - patch #4 adds extensive benchmarks and provide some analysis in commit
        message, it builds upon selftests/bpf's bench runner.
      - patch #5 adds most of patch #1 commit message as a doc under
        Documentation/bpf/ringbuf.rst.
      
      Litmus tests, validating consumer/producer protocols and memory orderings,
      were moved out as discussed in [1] and are going to be posted against -rcu
      tree and put under Documentation/litmus-tests/bpf-rb.
      
        [0] https://docs.google.com/presentation/d/18ITdg77Bj6YDOH2LghxrnFxiPWe0fAqcmJY95t_qr0w
        [1] https://lkml.org/lkml/2020/5/22/1011
      
      v3->v4:
      - fix ringbuf freeing (vunmap, __free_page); verified with a trivial loop
        creating and closing ringbuf map endlessly (Daniel);
      
      v2->v3:
      - dropped unnecessary smp_wmb() (Paul);
      - verifier reference type enhancement patch was dropped (Alexei);
      - better verifier message for various memory access checks (Alexei);
      - clarified a bit roundup_len() bit shifting (Alexei);
      - converted doc to .rst (Alexei);
      - fixed warning on 32-bit arches regarding tautological ring area size check.
      
      v1->v2:
      - commit()/discard()/output() accept flags (NO_WAKEUP/FORCE_WAKEUP) (Stanislav);
      - bpf_ringbuf_query() added, returning available data size, ringbuf size,
        consumer/producer positions, needed to implement smarter notification policy
        (Stanislav);
      - added ringbuf UAPI constants to include/uapi/linux/bpf.h (Jonathan);
      - fixed sample size check, added proper ringbuf size check (Jonathan, Alexei);
      - wake_up_all() is done through irq_work (Alexei);
      - consistent use of smp_load_acquire/smp_store_release, no
        READ_ONCE/WRITE_ONCE (Alexei);
      - added Documentation/bpf/ringbuf.txt (Stanislav);
      - updated litmus test with smp_load_acquire/smp_store_release changes;
      - added ring_buffer__consume() API to libbpf for busy-polling;
      - ring_buffer__poll() on success returns number of records consumed;
      - fixed EPOLL notifications, don't assume available data, done similarly to
        perfbuf's implementation;
      - both ringbuf and perfbuf now have --rb-sampled mode, instead of
        pb-raw/pb-custom mode, updated benchmark results;
      - extended ringbuf selftests to validate epoll logic/manual notification
        logic, as well as bpf_ringbuf_query().
      ====================
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      e255d327
    • Anton Protopopov's avatar
      selftests/bpf: Add tests for write-only stacks/queues · 43dd115b
      Anton Protopopov authored
      For write-only stacks and queues bpf_map_update_elem should be allowed, but
      bpf_map_lookup_elem and bpf_map_lookup_and_delete_elem should fail with EPERM.
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200527185700.14658-6-a.s.protopopov@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      43dd115b
    • Andrii Nakryiko's avatar
      docs/bpf: Add BPF ring buffer design notes · 97abb2b3
      Andrii Nakryiko authored
      Add commit description from patch #1 as a stand-alone documentation under
      Documentation/bpf, as it might be more convenient format, in long term
      perspective.
      Suggested-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200529075424.3139988-6-andriin@fb.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      97abb2b3
    • Andrii Nakryiko's avatar
      bpf: Add BPF ringbuf and perf buffer benchmarks · c97099b0
      Andrii Nakryiko authored
      Extend bench framework with ability to have benchmark-provided child argument
      parser for custom benchmark-specific parameters. This makes bench generic code
      modular and independent from any specific benchmark.
      
      Also implement a set of benchmarks for new BPF ring buffer and existing perf
      buffer. 4 benchmarks were implemented: 2 variations for each of BPF ringbuf
      and perfbuf:,
        - rb-libbpf utilizes stock libbpf ring_buffer manager for reading data;
        - rb-custom implements custom ring buffer setup and reading code, to
          eliminate overheads inherent in generic libbpf code due to callback
          functions and the need to update consumer position after each consumed
          record, instead of batching updates (due to pessimistic assumption that
          user callback might take long time and thus could unnecessarily hold ring
          buffer space for too long);
        - pb-libbpf uses stock libbpf perf_buffer code with all the default
          settings, though uses higher-performance raw event callback to minimize
          unnecessary overhead;
        - pb-custom implements its own custom consumer code to minimize any possible
          overhead of generic libbpf implementation and indirect function calls.
      
      All of the test support default, no data notification skipped, mode, as well
      as sampled mode (with --rb-sampled flag), which allows to trigger epoll
      notification less frequently and reduce overhead. As will be shown, this mode
      is especially critical for perf buffer, which suffers from high overhead of
      wakeups in kernel.
      
      Otherwise, all benchamrks implement similar way to generate a batch of records
      by using fentry/sys_getpgid BPF program, which pushes a bunch of records in
      a tight loop and records number of successful and dropped samples. Each record
      is a small 8-byte integer, to minimize the effect of memory copying with
      bpf_perf_event_output() and bpf_ringbuf_output().
      
      Benchmarks that have only one producer implement optional back-to-back mode,
      in which record production and consumption is alternating on the same CPU.
      This is the highest-throughput happy case, showing ultimate performance
      achievable with either BPF ringbuf or perfbuf.
      
      All the below scenarios are implemented in a script in
      benchs/run_bench_ringbufs.sh. Tests were performed on 28-core/56-thread
      Intel Xeon CPU E5-2680 v4 @ 2.40GHz CPU.
      
      Single-producer, parallel producer
      ==================================
      rb-libbpf            12.054 ± 0.320M/s (drops 0.000 ± 0.000M/s)
      rb-custom            8.158 ± 0.118M/s (drops 0.001 ± 0.003M/s)
      pb-libbpf            0.931 ± 0.007M/s (drops 0.000 ± 0.000M/s)
      pb-custom            0.965 ± 0.003M/s (drops 0.000 ± 0.000M/s)
      
      Single-producer, parallel producer, sampled notification
      ========================================================
      rb-libbpf            11.563 ± 0.067M/s (drops 0.000 ± 0.000M/s)
      rb-custom            15.895 ± 0.076M/s (drops 0.000 ± 0.000M/s)
      pb-libbpf            9.889 ± 0.032M/s (drops 0.000 ± 0.000M/s)
      pb-custom            9.866 ± 0.028M/s (drops 0.000 ± 0.000M/s)
      
      Single producer on one CPU, consumer on another one, both running at full
      speed. Curiously, rb-libbpf has higher throughput than objectively faster (due
      to more lightweight consumer code path) rb-custom. It appears that faster
      consumer causes kernel to send notifications more frequently, because consumer
      appears to be caught up more frequently. Performance of perfbuf suffers from
      default "no sampling" policy and huge overhead that causes.
      
      In sampled mode, rb-custom is winning very significantly eliminating too
      frequent in-kernel wakeups, the gain appears to be more than 2x.
      
      Perf buffer achieves even more impressive wins, compared to stock perfbuf
      settings, with 10x improvements in throughput with 1:500 sampling rate. The
      trade-off is that with sampling, application might not get next X events until
      X+1st arrives, which is not always acceptable. With steady influx of events,
      though, this shouldn't be a problem.
      
      Overall, single-producer performance of ring buffers seems to be better no
      matter the sampled/non-sampled modes, but it especially beats ring buffer
      without sampling due to its adaptive notification approach.
      
      Single-producer, back-to-back mode
      ==================================
      rb-libbpf            15.507 ± 0.247M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf-sampled    14.692 ± 0.195M/s (drops 0.000 ± 0.000M/s)
      rb-custom            21.449 ± 0.157M/s (drops 0.000 ± 0.000M/s)
      rb-custom-sampled    20.024 ± 0.386M/s (drops 0.000 ± 0.000M/s)
      pb-libbpf            1.601 ± 0.015M/s (drops 0.000 ± 0.000M/s)
      pb-libbpf-sampled    8.545 ± 0.064M/s (drops 0.000 ± 0.000M/s)
      pb-custom            1.607 ± 0.022M/s (drops 0.000 ± 0.000M/s)
      pb-custom-sampled    8.988 ± 0.144M/s (drops 0.000 ± 0.000M/s)
      
      Here we test a back-to-back mode, which is arguably best-case scenario both
      for BPF ringbuf and perfbuf, because there is no contention and for ringbuf
      also no excessive notification, because consumer appears to be behind after
      the first record. For ringbuf, custom consumer code clearly wins with 21.5 vs
      16 million records per second exchanged between producer and consumer. Sampled
      mode actually hurts a bit due to slightly slower producer logic (it needs to
      fetch amount of data available to decide whether to skip or force notification).
      
      Perfbuf with wakeup sampling gets 5.5x throughput increase, compared to
      no-sampling version. There also doesn't seem to be noticeable overhead from
      generic libbpf handling code.
      
      Perfbuf back-to-back, effect of sample rate
      ===========================================
      pb-sampled-1         1.035 ± 0.012M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-5         3.476 ± 0.087M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-10        5.094 ± 0.136M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-25        7.118 ± 0.153M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-50        8.169 ± 0.156M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-100       8.887 ± 0.136M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-250       9.180 ± 0.209M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-500       9.353 ± 0.281M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-1000      9.411 ± 0.217M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-2000      9.464 ± 0.167M/s (drops 0.000 ± 0.000M/s)
      pb-sampled-3000      9.575 ± 0.273M/s (drops 0.000 ± 0.000M/s)
      
      This benchmark shows the effect of event sampling for perfbuf. Back-to-back
      mode for highest throughput. Just doing every 5th record notification gives
      3.5x speed up. 250-500 appears to be the point of diminishing return, with
      almost 9x speed up. Most benchmarks use 500 as the default sampling for pb-raw
      and pb-custom.
      
      Ringbuf back-to-back, effect of sample rate
      ===========================================
      rb-sampled-1         1.106 ± 0.010M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-5         4.746 ± 0.149M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-10        7.706 ± 0.164M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-25        12.893 ± 0.273M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-50        15.961 ± 0.361M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-100       18.203 ± 0.445M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-250       19.962 ± 0.786M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-500       20.881 ± 0.551M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-1000      21.317 ± 0.532M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-2000      21.331 ± 0.535M/s (drops 0.000 ± 0.000M/s)
      rb-sampled-3000      21.688 ± 0.392M/s (drops 0.000 ± 0.000M/s)
      
      Similar benchmark for ring buffer also shows a great advantage (in terms of
      throughput) of skipping notifications. Skipping every 5th one gives 4x boost.
      Also similar to perfbuf case, 250-500 seems to be the point of diminishing
      returns, giving roughly 20x better results.
      
      Keep in mind, for this test, notifications are controlled manually with
      BPF_RB_NO_WAKEUP and BPF_RB_FORCE_WAKEUP. As can be seen from previous
      benchmarks, adaptive notifications based on consumer's positions provides same
      (or even slightly better due to simpler load generator on BPF side) benefits in
      favorable back-to-back scenario. Over zealous and fast consumer, which is
      almost always caught up, will make thoughput numbers smaller. That's the case
      when manual notification control might prove to be extremely beneficial.
      
      Ringbuf back-to-back, reserve+commit vs output
      ==============================================
      reserve              22.819 ± 0.503M/s (drops 0.000 ± 0.000M/s)
      output               18.906 ± 0.433M/s (drops 0.000 ± 0.000M/s)
      
      Ringbuf sampled, reserve+commit vs output
      =========================================
      reserve-sampled      15.350 ± 0.132M/s (drops 0.000 ± 0.000M/s)
      output-sampled       14.195 ± 0.144M/s (drops 0.000 ± 0.000M/s)
      
      BPF ringbuf supports two sets of APIs with various usability and performance
      tradeoffs: bpf_ringbuf_reserve()+bpf_ringbuf_commit() vs bpf_ringbuf_output().
      This benchmark clearly shows superiority of reserve+commit approach, despite
      using a small 8-byte record size.
      
      Single-producer, consumer/producer competing on the same CPU, low batch count
      =============================================================================
      rb-libbpf            3.045 ± 0.020M/s (drops 3.536 ± 0.148M/s)
      rb-custom            3.055 ± 0.022M/s (drops 3.893 ± 0.066M/s)
      pb-libbpf            1.393 ± 0.024M/s (drops 0.000 ± 0.000M/s)
      pb-custom            1.407 ± 0.016M/s (drops 0.000 ± 0.000M/s)
      
      This benchmark shows one of the worst-case scenarios, in which producer and
      consumer do not coordinate *and* fight for the same CPU. No batch count and
      sampling settings were able to eliminate drops for ringbuffer, producer is
      just too fast for consumer to keep up. But ringbuf and perfbuf still able to
      pass through quite a lot of messages, which is more than enough for a lot of
      applications.
      
      Ringbuf, multi-producer contention
      ==================================
      rb-libbpf nr_prod 1  10.916 ± 0.399M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 2  4.931 ± 0.030M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 3  4.880 ± 0.006M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 4  3.926 ± 0.004M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 8  4.011 ± 0.004M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 12 3.967 ± 0.016M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 16 2.604 ± 0.030M/s (drops 0.001 ± 0.002M/s)
      rb-libbpf nr_prod 20 2.233 ± 0.003M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 24 2.085 ± 0.015M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 28 2.055 ± 0.004M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 32 1.962 ± 0.004M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 36 2.089 ± 0.005M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 40 2.118 ± 0.006M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 44 2.105 ± 0.004M/s (drops 0.000 ± 0.000M/s)
      rb-libbpf nr_prod 48 2.120 ± 0.058M/s (drops 0.000 ± 0.001M/s)
      rb-libbpf nr_prod 52 2.074 ± 0.024M/s (drops 0.007 ± 0.014M/s)
      
      Ringbuf uses a very short-duration spinlock during reservation phase, to check
      few invariants, increment producer count and set record header. This is the
      biggest point of contention for ringbuf implementation. This benchmark
      evaluates the effect of multiple competing writers on overall throughput of
      a single shared ringbuffer.
      
      Overall throughput drops almost 2x when going from single to two
      highly-contended producers, gradually dropping with additional competing
      producers.  Performance drop stabilizes at around 20 producers and hovers
      around 2mln even with 50+ fighting producers, which is a 5x drop compared to
      non-contended case. Good kernel implementation in kernel helps maintain decent
      performance here.
      
      Note, that in the intended real-world scenarios, it's not expected to get even
      close to such a high levels of contention. But if contention will become
      a problem, there is always an option of sharding few ring buffers across a set
      of CPUs.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200529075424.3139988-5-andriin@fb.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      c97099b0
    • Andrii Nakryiko's avatar
      selftests/bpf: Add BPF ringbuf selftests · cb1c9ddd
      Andrii Nakryiko authored
      Both singleton BPF ringbuf and BPF ringbuf with map-in-map use cases are tested.
      Also reserve+submit/discards and output variants of API are validated.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200529075424.3139988-4-andriin@fb.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      cb1c9ddd
    • Andrii Nakryiko's avatar
      libbpf: Add BPF ring buffer support · bf99c936
      Andrii Nakryiko authored
      Declaring and instantiating BPF ring buffer doesn't require any changes to
      libbpf, as it's just another type of maps. So using existing BTF-defined maps
      syntax with __uint(type, BPF_MAP_TYPE_RINGBUF) and __uint(max_elements,
      <size-of-ring-buf>) is all that's necessary to create and use BPF ring buffer.
      
      This patch adds BPF ring buffer consumer to libbpf. It is very similar to
      perf_buffer implementation in terms of API, but also attempts to fix some
      minor problems and inconveniences with existing perf_buffer API.
      
      ring_buffer support both single ring buffer use case (with just using
      ring_buffer__new()), as well as allows to add more ring buffers, each with its
      own callback and context. This allows to efficiently poll and consume
      multiple, potentially completely independent, ring buffers, using single
      epoll instance.
      
      The latter is actually a problem in practice for applications
      that are using multiple sets of perf buffers. They have to create multiple
      instances for struct perf_buffer and poll them independently or in a loop,
      each approach having its own problems (e.g., inability to use a common poll
      timeout). struct ring_buffer eliminates this problem by aggregating many
      independent ring buffer instances under the single "ring buffer manager".
      
      Second, perf_buffer's callback can't return error, so applications that need
      to stop polling due to error in data or data signalling the end, have to use
      extra mechanisms to signal that polling has to stop. ring_buffer's callback
      can return error, which will be passed through back to user code and can be
      acted upon appropariately.
      
      Two APIs allow to consume ring buffer data:
        - ring_buffer__poll(), which will wait for data availability notification
          and will consume data only from reported ring buffer(s); this API allows
          to efficiently use resources by reading data only when it becomes
          available;
        - ring_buffer__consume(), will attempt to read new records regardless of
          data availablity notification sub-system. This API is useful for cases
          when lowest latency is required, in expense of burning CPU resources.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200529075424.3139988-3-andriin@fb.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      bf99c936
    • Andrii Nakryiko's avatar
      bpf: Implement BPF ring buffer and verifier support for it · 457f4436
      Andrii Nakryiko authored
      This commit adds a new MPSC ring buffer implementation into BPF ecosystem,
      which allows multiple CPUs to submit data to a single shared ring buffer. On
      the consumption side, only single consumer is assumed.
      
      Motivation
      ----------
      There are two distinctive motivators for this work, which are not satisfied by
      existing perf buffer, which prompted creation of a new ring buffer
      implementation.
        - more efficient memory utilization by sharing ring buffer across CPUs;
        - preserving ordering of events that happen sequentially in time, even
        across multiple CPUs (e.g., fork/exec/exit events for a task).
      
      These two problems are independent, but perf buffer fails to satisfy both.
      Both are a result of a choice to have per-CPU perf ring buffer.  Both can be
      also solved by having an MPSC implementation of ring buffer. The ordering
      problem could technically be solved for perf buffer with some in-kernel
      counting, but given the first one requires an MPSC buffer, the same solution
      would solve the second problem automatically.
      
      Semantics and APIs
      ------------------
      Single ring buffer is presented to BPF programs as an instance of BPF map of
      type BPF_MAP_TYPE_RINGBUF. Two other alternatives considered, but ultimately
      rejected.
      
      One way would be to, similar to BPF_MAP_TYPE_PERF_EVENT_ARRAY, make
      BPF_MAP_TYPE_RINGBUF could represent an array of ring buffers, but not enforce
      "same CPU only" rule. This would be more familiar interface compatible with
      existing perf buffer use in BPF, but would fail if application needed more
      advanced logic to lookup ring buffer by arbitrary key. HASH_OF_MAPS addresses
      this with current approach. Additionally, given the performance of BPF
      ringbuf, many use cases would just opt into a simple single ring buffer shared
      among all CPUs, for which current approach would be an overkill.
      
      Another approach could introduce a new concept, alongside BPF map, to
      represent generic "container" object, which doesn't necessarily have key/value
      interface with lookup/update/delete operations. This approach would add a lot
      of extra infrastructure that has to be built for observability and verifier
      support. It would also add another concept that BPF developers would have to
      familiarize themselves with, new syntax in libbpf, etc. But then would really
      provide no additional benefits over the approach of using a map.
      BPF_MAP_TYPE_RINGBUF doesn't support lookup/update/delete operations, but so
      doesn't few other map types (e.g., queue and stack; array doesn't support
      delete, etc).
      
      The approach chosen has an advantage of re-using existing BPF map
      infrastructure (introspection APIs in kernel, libbpf support, etc), being
      familiar concept (no need to teach users a new type of object in BPF program),
      and utilizing existing tooling (bpftool). For common scenario of using
      a single ring buffer for all CPUs, it's as simple and straightforward, as
      would be with a dedicated "container" object. On the other hand, by being
      a map, it can be combined with ARRAY_OF_MAPS and HASH_OF_MAPS map-in-maps to
      implement a wide variety of topologies, from one ring buffer for each CPU
      (e.g., as a replacement for perf buffer use cases), to a complicated
      application hashing/sharding of ring buffers (e.g., having a small pool of
      ring buffers with hashed task's tgid being a look up key to preserve order,
      but reduce contention).
      
      Key and value sizes are enforced to be zero. max_entries is used to specify
      the size of ring buffer and has to be a power of 2 value.
      
      There are a bunch of similarities between perf buffer
      (BPF_MAP_TYPE_PERF_EVENT_ARRAY) and new BPF ring buffer semantics:
        - variable-length records;
        - if there is no more space left in ring buffer, reservation fails, no
          blocking;
        - memory-mappable data area for user-space applications for ease of
          consumption and high performance;
        - epoll notifications for new incoming data;
        - but still the ability to do busy polling for new data to achieve the
          lowest latency, if necessary.
      
      BPF ringbuf provides two sets of APIs to BPF programs:
        - bpf_ringbuf_output() allows to *copy* data from one place to a ring
          buffer, similarly to bpf_perf_event_output();
        - bpf_ringbuf_reserve()/bpf_ringbuf_commit()/bpf_ringbuf_discard() APIs
          split the whole process into two steps. First, a fixed amount of space is
          reserved. If successful, a pointer to a data inside ring buffer data area
          is returned, which BPF programs can use similarly to a data inside
          array/hash maps. Once ready, this piece of memory is either committed or
          discarded. Discard is similar to commit, but makes consumer ignore the
          record.
      
      bpf_ringbuf_output() has disadvantage of incurring extra memory copy, because
      record has to be prepared in some other place first. But it allows to submit
      records of the length that's not known to verifier beforehand. It also closely
      matches bpf_perf_event_output(), so will simplify migration significantly.
      
      bpf_ringbuf_reserve() avoids the extra copy of memory by providing a memory
      pointer directly to ring buffer memory. In a lot of cases records are larger
      than BPF stack space allows, so many programs have use extra per-CPU array as
      a temporary heap for preparing sample. bpf_ringbuf_reserve() avoid this needs
      completely. But in exchange, it only allows a known constant size of memory to
      be reserved, such that verifier can verify that BPF program can't access
      memory outside its reserved record space. bpf_ringbuf_output(), while slightly
      slower due to extra memory copy, covers some use cases that are not suitable
      for bpf_ringbuf_reserve().
      
      The difference between commit and discard is very small. Discard just marks
      a record as discarded, and such records are supposed to be ignored by consumer
      code. Discard is useful for some advanced use-cases, such as ensuring
      all-or-nothing multi-record submission, or emulating temporary malloc()/free()
      within single BPF program invocation.
      
      Each reserved record is tracked by verifier through existing
      reference-tracking logic, similar to socket ref-tracking. It is thus
      impossible to reserve a record, but forget to submit (or discard) it.
      
      bpf_ringbuf_query() helper allows to query various properties of ring buffer.
      Currently 4 are supported:
        - BPF_RB_AVAIL_DATA returns amount of unconsumed data in ring buffer;
        - BPF_RB_RING_SIZE returns the size of ring buffer;
        - BPF_RB_CONS_POS/BPF_RB_PROD_POS returns current logical possition of
          consumer/producer, respectively.
      Returned values are momentarily snapshots of ring buffer state and could be
      off by the time helper returns, so this should be used only for
      debugging/reporting reasons or for implementing various heuristics, that take
      into account highly-changeable nature of some of those characteristics.
      
      One such heuristic might involve more fine-grained control over poll/epoll
      notifications about new data availability in ring buffer. Together with
      BPF_RB_NO_WAKEUP/BPF_RB_FORCE_WAKEUP flags for output/commit/discard helpers,
      it allows BPF program a high degree of control and, e.g., more efficient
      batched notifications. Default self-balancing strategy, though, should be
      adequate for most applications and will work reliable and efficiently already.
      
      Design and implementation
      -------------------------
      This reserve/commit schema allows a natural way for multiple producers, either
      on different CPUs or even on the same CPU/in the same BPF program, to reserve
      independent records and work with them without blocking other producers. This
      means that if BPF program was interruped by another BPF program sharing the
      same ring buffer, they will both get a record reserved (provided there is
      enough space left) and can work with it and submit it independently. This
      applies to NMI context as well, except that due to using a spinlock during
      reservation, in NMI context, bpf_ringbuf_reserve() might fail to get a lock,
      in which case reservation will fail even if ring buffer is not full.
      
      The ring buffer itself internally is implemented as a power-of-2 sized
      circular buffer, with two logical and ever-increasing counters (which might
      wrap around on 32-bit architectures, that's not a problem):
        - consumer counter shows up to which logical position consumer consumed the
          data;
        - producer counter denotes amount of data reserved by all producers.
      
      Each time a record is reserved, producer that "owns" the record will
      successfully advance producer counter. At that point, data is still not yet
      ready to be consumed, though. Each record has 8 byte header, which contains
      the length of reserved record, as well as two extra bits: busy bit to denote
      that record is still being worked on, and discard bit, which might be set at
      commit time if record is discarded. In the latter case, consumer is supposed
      to skip the record and move on to the next one. Record header also encodes
      record's relative offset from the beginning of ring buffer data area (in
      pages). This allows bpf_ringbuf_commit()/bpf_ringbuf_discard() to accept only
      the pointer to the record itself, without requiring also the pointer to ring
      buffer itself. Ring buffer memory location will be restored from record
      metadata header. This significantly simplifies verifier, as well as improving
      API usability.
      
      Producer counter increments are serialized under spinlock, so there is
      a strict ordering between reservations. Commits, on the other hand, are
      completely lockless and independent. All records become available to consumer
      in the order of reservations, but only after all previous records where
      already committed. It is thus possible for slow producers to temporarily hold
      off submitted records, that were reserved later.
      
      Reservation/commit/consumer protocol is verified by litmus tests in
      Documentation/litmus-test/bpf-rb.
      
      One interesting implementation bit, that significantly simplifies (and thus
      speeds up as well) implementation of both producers and consumers is how data
      area is mapped twice contiguously back-to-back in the virtual memory. This
      allows to not take any special measures for samples that have to wrap around
      at the end of the circular buffer data area, because the next page after the
      last data page would be first data page again, and thus the sample will still
      appear completely contiguous in virtual memory. See comment and a simple ASCII
      diagram showing this visually in bpf_ringbuf_area_alloc().
      
      Another feature that distinguishes BPF ringbuf from perf ring buffer is
      a self-pacing notifications of new data being availability.
      bpf_ringbuf_commit() implementation will send a notification of new record
      being available after commit only if consumer has already caught up right up
      to the record being committed. If not, consumer still has to catch up and thus
      will see new data anyways without needing an extra poll notification.
      Benchmarks (see tools/testing/selftests/bpf/benchs/bench_ringbuf.c) show that
      this allows to achieve a very high throughput without having to resort to
      tricks like "notify only every Nth sample", which are necessary with perf
      buffer. For extreme cases, when BPF program wants more manual control of
      notifications, commit/discard/output helpers accept BPF_RB_NO_WAKEUP and
      BPF_RB_FORCE_WAKEUP flags, which give full control over notifications of data
      availability, but require extra caution and diligence in using this API.
      
      Comparison to alternatives
      --------------------------
      Before considering implementing BPF ring buffer from scratch existing
      alternatives in kernel were evaluated, but didn't seem to meet the needs. They
      largely fell into few categores:
        - per-CPU buffers (perf, ftrace, etc), which don't satisfy two motivations
          outlined above (ordering and memory consumption);
        - linked list-based implementations; while some were multi-producer designs,
          consuming these from user-space would be very complicated and most
          probably not performant; memory-mapping contiguous piece of memory is
          simpler and more performant for user-space consumers;
        - io_uring is SPSC, but also requires fixed-sized elements. Naively turning
          SPSC queue into MPSC w/ lock would have subpar performance compared to
          locked reserve + lockless commit, as with BPF ring buffer. Fixed sized
          elements would be too limiting for BPF programs, given existing BPF
          programs heavily rely on variable-sized perf buffer already;
        - specialized implementations (like a new printk ring buffer, [0]) with lots
          of printk-specific limitations and implications, that didn't seem to fit
          well for intended use with BPF programs.
      
        [0] https://lwn.net/Articles/779550/Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200529075424.3139988-2-andriin@fb.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      457f4436
    • Anton Protopopov's avatar
      bpf: Fix map permissions check · 1ea0f912
      Anton Protopopov authored
      The map_lookup_and_delete_elem() function should check for both FMODE_CAN_WRITE
      and FMODE_CAN_READ permissions because it returns a map element to user space.
      
      Fixes: bd513cd0 ("bpf: add MAP_LOOKUP_AND_DELETE_ELEM syscall")
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200527185700.14658-5-a.s.protopopov@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      1ea0f912
    • Anton Protopopov's avatar
      selftests/bpf: Cleanup comments in test_maps · efbc3b8f
      Anton Protopopov authored
      Make comments inside the test_map_rdonly and test_map_wronly tests
      consistent with logic.
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200527185700.14658-4-a.s.protopopov@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      efbc3b8f
    • Anton Protopopov's avatar
      selftests/bpf: Cleanup some file descriptors in test_maps · 36ef9a2d
      Anton Protopopov authored
      The test_map_rdonly and test_map_wronly tests should close file descriptors
      which they open.
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200527185700.14658-3-a.s.protopopov@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      36ef9a2d
    • Anton Protopopov's avatar
      selftests/bpf: Fix a typo in test_maps · 204fb041
      Anton Protopopov authored
      Trivial fix to a typo in the test_map_wronly test: "read" -> "write"
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200527185700.14658-2-a.s.protopopov@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      204fb041
    • Eelco Chaudron's avatar
      libbpf: Fix perf_buffer__free() API for sparse allocs · 601b05ca
      Eelco Chaudron authored
      In case the cpu_bufs are sparsely allocated they are not all
      free'ed. These changes will fix this.
      
      Fixes: fb84b822 ("libbpf: add perf buffer API")
      Signed-off-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/159056888305.330763.9684536967379110349.stgit@ebuildSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      601b05ca
    • John Fastabend's avatar
      bpf, selftests: Test probe_* helpers from SCHED_CLS · ee103e9f
      John Fastabend authored
      Lets test using probe* in SCHED_CLS network programs as well just
      to be sure these keep working. Its cheap to add the extra test
      and provides a second context to test outside of sk_msg after
      we generalized probe* helpers to all networking types.
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/159033911685.12355.15951980509828906214.stgit@john-Precision-5820-TowerSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      ee103e9f
    • John Fastabend's avatar
      bpf, selftests: Add sk_msg helpers load and attach test · 1d9c037a
      John Fastabend authored
      The test itself is not particularly useful but it encodes a common
      pattern we have.
      
      Namely do a sk storage lookup then depending on data here decide if
      we need to do more work or alternatively allow packet to PASS. Then
      if we need to do more work consult task_struct for more information
      about the running task. Finally based on this additional information
      drop or pass the data. In this case the suspicious check is not so
      realisitic but it encodes the general pattern and uses the helpers
      so we test the workflow.
      
      This is a load test to ensure verifier correctly handles this case.
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/159033909665.12355.6166415847337547879.stgit@john-Precision-5820-TowerSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      1d9c037a
    • John Fastabend's avatar
    • John Fastabend's avatar
      bpf: Extend bpf_base_func_proto helpers with probe_* and *current_task* · f470378c
      John Fastabend authored
      Often it is useful when applying policy to know something about the
      task. If the administrator has CAP_SYS_ADMIN rights then they can
      use kprobe + networking hook and link the two programs together to
      accomplish this. However, this is a bit clunky and also means we have
      to call both the network program and kprobe program when we could just
      use a single program and avoid passing metadata through sk_msg/skb->cb,
      socket, maps, etc.
      
      To accomplish this add probe_* helpers to bpf_base_func_proto programs
      guarded by a perfmon_capable() check. New supported helpers are the
      following,
      
       BPF_FUNC_get_current_task
       BPF_FUNC_probe_read_user
       BPF_FUNC_probe_read_kernel
       BPF_FUNC_probe_read_user_str
       BPF_FUNC_probe_read_kernel_str
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/159033905529.12355.4368381069655254932.stgit@john-Precision-5820-TowerSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      f470378c
    • John Fastabend's avatar
      bpf, sk_msg: Add some generic helpers that may be useful from sk_msg · abe3cac8
      John Fastabend authored
      Add these generic helpers that may be useful to use from sk_msg programs.
      The helpers do not depend on ctx so we can simply add them here,
      
       BPF_FUNC_perf_event_output
       BPF_FUNC_get_current_uid_gid
       BPF_FUNC_get_current_pid_tgid
       BPF_FUNC_get_current_cgroup_id
       BPF_FUNC_get_current_ancestor_cgroup_id
       BPF_FUNC_get_cgroup_classid
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/159033903373.12355.15489763099696629346.stgit@john-Precision-5820-TowerSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      abe3cac8
    • Yauheni Kaliuta's avatar
      libbpf: Use .so dynamic symbols for abi check · 55983299
      Yauheni Kaliuta authored
      Since dynamic symbols are used for dynamic linking it makes sense to
      use them (readelf --dyn-syms) for abi check.
      
      Found with some configuration on powerpc where linker puts
      local *.plt_call.* symbols into .so.
      Signed-off-by: default avatarYauheni Kaliuta <yauheni.kaliuta@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20200525061846.16524-1-yauheni.kaliuta@redhat.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      55983299
    • Chris Packham's avatar
    • Nikolay Borisov's avatar
      libbpf: Install headers as part of make install · 93581359
      Nikolay Borisov authored
      Current 'make install' results in only pkg-config and library binaries
      being installed. For consistency also install headers as part of
      "make install"
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20200526174612.5447-1-nborisov@suse.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      93581359
    • Eelco Chaudron's avatar
      libbpf: Add API to consume the perf ring buffer content · 272d51af
      Eelco Chaudron authored
      This new API, perf_buffer__consume, can be used as follows:
      
      - When you have a perf ring where wakeup_events is higher than 1,
        and you have remaining data in the rings you would like to pull
        out on exit (or maybe based on a timeout).
      
      - For low latency cases where you burn a CPU that constantly polls
        the queues.
      Signed-off-by: default avatarEelco Chaudron <echaudro@redhat.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/159048487929.89441.7465713173442594608.stgit@ebuildSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      272d51af
    • Lukas Bulwahn's avatar
      MAINTAINERS: Adjust entry in XDP SOCKETS to actual file name · 2b983b40
      Lukas Bulwahn authored
      Commit 2b43470a ("xsk: Introduce AF_XDP buffer allocation API") added a
      new header file include/net/xsk_buff_pool.h, but commit 28bee21d
      ("MAINTAINERS, xsk: Update AF_XDP section after moves/adds") added a file
      entry referring to include/net/xsk_buffer_pool.h.
      
      Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
      
        warning: no file matches  F:  include/net/xsk_buffer_pool.h
      
      Adjust the entry in XDP SOCKETS to the actual file name.
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200525141553.7035-1-lukas.bulwahn@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2b983b40
    • Jakub Sitnicki's avatar
      bpf: Fix returned error sign when link doesn't support updates · fe537393
      Jakub Sitnicki authored
      System calls encode returned errors as negative values. Fix a typo that
      breaks this convention for bpf(LINK_UPDATE) when bpf_link doesn't support
      update operation.
      
      Fixes: f9d04127 ("bpf: Refactor bpf_link update handling")
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200525122928.1164495-1-jakub@cloudflare.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      fe537393
    • Tobias Klauser's avatar
      tools, bpftool: Print correct error message when failing to load BTF · dc3ca5cf
      Tobias Klauser authored
      btf__parse_raw and btf__parse_elf return negative error numbers wrapped
      in an ERR_PTR, so the extracted value needs to be negated before passing
      them to strerror which expects a positive error number.
      
      Before:
        Error: failed to load BTF from .../vmlinux: Unknown error -2
      
      After:
        Error: failed to load BTF from .../vmlinux: No such file or directory
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200525135421.4154-1-tklauser@distanz.chSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      dc3ca5cf
    • Quentin Monnet's avatar
      tools, bpftool: Make capability check account for new BPF caps · 73a4f040
      Quentin Monnet authored
      Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
      to other capabilities for various BPF features, update the capability
      checks (and potentially, drops) in bpftool for feature probes. Because
      bpftool and/or the system might not know of CAP_BPF yet, some caution is
      necessary:
      
      - If compiled and run on a system with CAP_BPF, check CAP_BPF,
        CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
      
      - Guard against CAP_BPF being undefined, to allow compiling bpftool from
        latest sources on older systems. If the system where feature probes
        are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
        as this should be the only capability required for all the BPF
        probing.
      
      - If compiled from latest sources on a system without CAP_BPF, but later
        executed on a newer system with CAP_BPF knowledge, then we only test
        CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
        CAP_SYS_ADMIN but misses the other capabilities. The alternative would
        be to redefine the value for CAP_BPF in bpftool, but this does not
        look clean, and the case sounds relatively rare anyway.
      
      Note that libcap offers a cap_to_name() function to retrieve the name of
      a given capability (e.g. "cap_sys_admin"). We do not use it because
      deriving the names from the macros looks simpler than using
      cap_to_name() (doing a strdup() on the string) + cap_free() + handling
      the case of failed allocations, when we just want to use the name of the
      capability in an error message.
      
      The checks when compiling without libcap (i.e. root versus non-root) are
      unchanged.
      
      v2:
      - Do not allocate cap_list dynamically.
      - Drop BPF-related capabilities when running with "unprivileged", even
        if we didn't have the full set in the first place (in v1, we would
        skip dropping them in that case).
      - Keep track of what capabilities we have, print the names of the
        missing ones for privileged probing.
      - Attempt to drop only the capabilities we actually have.
      - Rename a couple variables.
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      73a4f040
    • Quentin Monnet's avatar
      tools, bpftool: Clean subcommand help messages · 90040351
      Quentin Monnet authored
      This is a clean-up for the formatting of the do_help functions for
      bpftool's subcommands. The following fixes are included:
      
      - Do not use argv[-2] for "iter" help message, as the help is shown by
        default if no "iter" action is selected, resulting in messages looking
        like "./bpftool bpftool pin...".
      
      - Do not print unused HELP_SPEC_PROGRAM in help message for "bpftool
        link".
      
      - Andrii used argument indexing to avoid having multiple occurrences of
        bin_name and argv[-2] in the fprintf() for the help message, for
        "bpftool gen" and "bpftool link". Let's reuse this for all other help
        functions. We can remove up to thirty arguments for the "bpftool map"
        help message.
      
      - Harmonise all functions, e.g. use ending quotes-comma on a separate
        line.
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200523010751.23465-1-quentin@isovalent.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      90040351
    • Vladimir Oltean's avatar
      net: dsa: sja1105: suppress -Wmissing-prototypes in sja1105_vl.c · eae9d3c0
      Vladimir Oltean authored
      Newer C compilers are complaining about the fact that there are no
      function prototypes in sja1105_vl.c for the non-static functions.
      Give them what they want.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eae9d3c0
    • David S. Miller's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 2a2e01e7
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      100GbE Intel Wired LAN Driver Updates 2020-05-31
      
      This series contains updates to the ice driver only.
      
      Brett modifies the driver to allow users to clear a VF's
      administratively set MAC address on the PF.  Fixes the driver to
      recognize an existing VLAN tag when DMAC/SMAC is enabled in a packet.
      Fixes an issue, so that VF's are reset after any VF port VLAN
      modifications are made on the PF.  Made sure the register QRXFLXP_CNTXT
      is cleared before writing a new value to ensure the previous value is
      not passed forward.  Updates the PF to allow the VF to request a reset
      as soon as it has been initialized.  Fixes an issue to ensure when a VSI
      is created, it uses the current coalesce value, not the default value.
      
      Paul allows untrusted VF's to add 16 filters.
      
      Dan increases the timeout needed after a PFR to allow ample time for
      package download.
      
      Chinh adjust the define value for the number of PHY speeds we currently
      support.  Changes the driver to ignore EMODE error when configuring the
      PHY.
      
      Jesse fixes an issue which was preventing a user from configuring the
      interface before bringing it up.
      
      Henry fixes the logic for adding back perfect flows after flow director
      filter does a deletion.
      
      Bruce fixes line wrappings to make it more consistent.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a2e01e7
    • Roopa Prabhu's avatar
      vxlan: fix dereference of nexthop group in nexthop update path · 03eaeda7
      Roopa Prabhu authored
      fix dereference of nexthop group in fdb nexthop group
      update validation path.
      
      Fixes: 1274e1cc ("vxlan: ecmp support for mac fdb entries")
      Reported-by: default avatarIdo Schimmel <idosch@idosch.org>
      Suggested-by: default avatarIdo Schimmel <idosch@idosch.org>
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03eaeda7
    • Al Viro's avatar
      switch cmsghdr_from_user_compat_to_kern() to copy_from_user() · 547ce4cf
      Al Viro authored
      no point getting compat_cmsghdr field-by-field
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      547ce4cf
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-add-PFC-support' · a477605f
      David S. Miller authored
      Ioana Ciornei says:
      
      ====================
      dpaa2-eth: add PFC support
      
      This patch set adds support for Priority Flow Control in DPAA2 Ethernet
      devices.
      
      The first patch make the necessary changes so that multiple
      traffic classes are configured. The dequeue priority
      of the maximum 8 traffic classes is configured to be equal.
      The second patch adds a static distribution to said traffic
      classes based on the VLAN PCP field. In the future, this could be
      extended through the .setapp() DCB callback for dynamic configuration.
      
      Also, add support for the congestion group taildrop mechanism that
      allows us to control the number of frames that can accumulate on a group
      of Rx frame queues belonging to the same traffic class.
      
      The basic subset of the DCB ops is implemented so that the user can
      query the number of PFC capable traffic classes, their state and
      reconfigure them if necessary.
      
      Changes in v3:
       - add patches 6-7 which add the PFC functionality
       - patch 2/7: revert to explicitly cast mask to u16 * to not get into
         sparse warnings
      Changes in v4:
       - really fix the sparse warnings in 2/7
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a477605f
    • Ioana Ciornei's avatar
      dpaa2-eth: Keep congestion group taildrop enabled when PFC on · 07beb165
      Ioana Ciornei authored
      Leave congestion group taildrop enabled for all traffic classes
      when PFC is enabled. Notification threshold is low enough such
      that it will be hit first and this also ensures that FQs on
      traffic classes which are not PFC enabled won't drain the buffer
      pool.
      
      FQ taildrop threshold is kept disabled as long as any form of
      flow control is on. Since FQ taildrop works with bytes, not number
      of frames, we can't guarantee it will not interfere with the
      congestion notification mechanism for all frame sizes.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07beb165
    • Ioana Ciornei's avatar
      dpaa2-eth: Add PFC support through DCB ops · f395b69f
      Ioana Ciornei authored
      Add support in dpaa2-eth for PFC (Priority Flow Control)
      through the DCB ops.
      
      Instruct the hardware to respond to received PFC frames.
      Current firmware doesn't allow us to selectively enable PFC
      on the Rx side for some priorities only, so we will react to
      all incoming PFC frames (and stop transmitting on the traffic
      classes specified in the frame).
      
      Also, configure the hardware to generate PFC frames based on Rx
      congestion notifications. When a certain number of frames accumulate in
      the ingress queues corresponding to a traffic class, priority flow
      control frames are generated for that TC.
      
      The number of PFC traffic classes available can be queried through
      lldptool. Also, which of those traffic classes have PFC enabled is also
      controlled through the same dcbnl_rtnl_ops callbacks.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f395b69f
    • Ioana Radulescu's avatar
      dpaa2-eth: Update FQ taildrop threshold and buffer pool count · 3f8b826d
      Ioana Radulescu authored
      Now that we have congestion group taildrop configured at all
      times, we can afford to increase the frame queue taildrop
      threshold; this will ensure a better response when receiving
      bursts of large-sized frames.
      
      Also decouple the buffer pool count from the Rx FQ taildrop
      threshold, as above change would increase it too much. Instead,
      keep the old count as a hardcoded value.
      
      With the new limits, we try to ensure that:
      * we allow enough leeway for large frame bursts (by buffering
      enough of them in queues to avoid heavy dropping in case of
      bursty traffic, but when overall ingress bandwidth is manageable)
      * allow pending frames to be evenly spread between ingress FQs,
      regardless of frame size
      * avoid dropping frames due to the buffer pool being empty; this
      is not a bad behaviour per se, but system overall response is
      more linear and predictable when frames are dropped at frame
      queue/group level.
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f8b826d
    • Ioana Radulescu's avatar
      dpaa2-eth: Add congestion group taildrop · 2c8d1c8d
      Ioana Radulescu authored
      The increase in number of ingress frame queues means we now risk
      depleting the buffer pool before the FQ taildrop kicks in.
      
      Congestion group taildrop allows us to control the number of frames that
      can accumulate on a group of Rx frame queues belonging to the same
      traffic class.  This setting coexists with the frame queue based
      taildrop: whichever limit gets hit first triggers the frame drop.
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c8d1c8d
    • Ioana Radulescu's avatar
      dpaa2-eth: Add helper functions · ad054f26
      Ioana Radulescu authored
      Add convenient helper functions that determines whether Rx/Tx pause
      frames are enabled based on link state flags received from firmware.
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad054f26
    • Ioana Radulescu's avatar
      dpaa2-eth: Distribute ingress frames based on VLAN prio · 6aa90fe2
      Ioana Radulescu authored
      Configure static ingress classification based on VLAN PCP field.
      If the DPNI doesn't have enough traffic classes to accommodate all
      priority levels, the lowest ones end up on TC 0 (default on miss).
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6aa90fe2
    • Ioana Radulescu's avatar
      dpaa2-eth: Add support for Rx traffic classes · 685e39ea
      Ioana Radulescu authored
      The firmware reserves for each DPNI a number of RX frame queues
      equal to the number of configured flows x number of configured
      traffic classes.
      
      Current driver configuration directs all incoming traffic to
      FQs corresponding to TC0, leaving all other priority levels unused.
      
      Start adding support for multiple ingress traffic classes, by
      configuring the FQs associated with all priority levels, not just
      TC0. All settings that are per-TC, such as those related to
      hashing and flow steering, are also updated.
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      685e39ea
    • Michael Walle's avatar
      net: phy: broadcom: don't export RDB/legacy access methods · 3190ca3b
      Michael Walle authored
      Don't export __bcm_phy_enable_rdb_access() and
      __bcm_phy_enable_legacy_access() functions. They aren't used outside this
      module and it was forgotten to provide a prototype for these functions.
      Just make them static for now.
      
      Fixes: 11ecf8c5 ("net: phy: broadcom: add cable test support")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3190ca3b
    • Willem de Bruijn's avatar
      tun: correct header offsets in napi frags mode · 96aa1b22
      Willem de Bruijn authored
      Tun in IFF_NAPI_FRAGS mode calls napi_gro_frags. Unlike netif_rx and
      netif_gro_receive, this expects skb->data to point to the mac layer.
      
      But skb_probe_transport_header, __skb_get_hash_symmetric, and
      xdp_do_generic in tun_get_user need skb->data to point to the network
      header. Flow dissection also needs skb->protocol set, so
      eth_type_trans has to be called.
      
      Ensure the link layer header lies in linear as eth_type_trans pulls
      ETH_HLEN. Then take the same code paths for frags as for not frags.
      Push the link layer header back just before calling napi_gro_frags.
      
      By pulling up to ETH_HLEN from frag0 into linear, this disables the
      frag0 optimization in the special case when IFF_NAPI_FRAGS is used
      with zero length iov[0] (and thus empty skb->linear).
      
      Fixes: 90e33d45 ("tun: enable napi_gro_frags() for TUN/TAP driver")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarPetar Penkov <ppenkov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96aa1b22