1. 22 5月, 2020 1 次提交
  2. 05 5月, 2020 1 次提交
  3. 29 2月, 2020 1 次提交
  4. 11 2月, 2020 1 次提交
    • M
      xsk: Publish global consumer pointers when NAPI is finished · 30744a68
      Magnus Karlsson 提交于
      The commit 4b638f13 ("xsk: Eliminate the RX batch size")
      introduced a much more lazy way of updating the global consumer
      pointers from the kernel side, by only doing so when running out of
      entries in the fill or Tx rings (the rings consumed by the
      kernel). This can result in a deadlock with the user application if
      the kernel requires more than one entry to proceed and the application
      cannot put these entries in the fill ring because the kernel has not
      updated the global consumer pointer since the ring is not empty.
      
      Fix this by publishing the local kernel side consumer pointer whenever
      we have completed Rx or Tx processing in the kernel. This way, user
      space will have an up-to-date view of the consumer pointers whenever it
      gets to execute in the one core case (application and driver on the
      same core), or after a certain number of packets have been processed
      in the two core case (application and driver on different cores).
      
      A side effect of this patch is that the one core case gets better
      performance, but the two core case gets worse. The reason that the one
      core case improves is that updating the global consumer pointer is
      relatively cheap since the application by definition is not running
      when the kernel is (they are on the same core) and it is beneficial
      for the application, once it gets to run, to have pointers that are
      as up to date as possible since it then can operate on more packets
      and buffers. In the two core case, the most important performance
      aspect is to minimize the number of accesses to the global pointers
      since they are shared between two cores and bounces between the caches
      of those cores. This patch results in more updates to global state,
      which means lower performance in the two core case.
      
      Fixes: 4b638f13 ("xsk: Eliminate the RX batch size")
      Reported-by: NRyan Goodfellow <rgoodfel@isi.edu>
      Reported-by: NMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Acked-by: NMaxim Mikityanskiy <maximmi@mellanox.com>
      Link: https://lore.kernel.org/bpf/1581348432-6747-1-git-send-email-magnus.karlsson@intel.com
      30744a68
  5. 21 12月, 2019 10 次提交
  6. 31 8月, 2019 1 次提交
  7. 18 8月, 2019 1 次提交
    • M
      xsk: add support for need_wakeup flag in AF_XDP rings · 77cd0d7b
      Magnus Karlsson 提交于
      This commit adds support for a new flag called need_wakeup in the
      AF_XDP Tx and fill rings. When this flag is set, it means that the
      application has to explicitly wake up the kernel Rx (for the bit in
      the fill ring) or kernel Tx (for bit in the Tx ring) processing by
      issuing a syscall. Poll() can wake up both depending on the flags
      submitted and sendto() will wake up tx processing only.
      
      The main reason for introducing this new flag is to be able to
      efficiently support the case when application and driver is executing
      on the same core. Previously, the driver was just busy-spinning on the
      fill ring if it ran out of buffers in the HW and there were none on
      the fill ring. This approach works when the application is running on
      another core as it can replenish the fill ring while the driver is
      busy-spinning. Though, this is a lousy approach if both of them are
      running on the same core as the probability of the fill ring getting
      more entries when the driver is busy-spinning is zero. With this new
      feature the driver now sets the need_wakeup flag and returns to the
      application. The application can then replenish the fill queue and
      then explicitly wake up the Rx processing in the kernel using the
      syscall poll(). For Tx, the flag is only set to one if the driver has
      no outstanding Tx completion interrupts. If it has some, the flag is
      zero as it will be woken up by a completion interrupt anyway.
      
      As a nice side effect, this new flag also improves the performance of
      the case where application and driver are running on two different
      cores as it reduces the number of syscalls to the kernel. The kernel
      tells user space if it needs to be woken up by a syscall, and this
      eliminates many of the syscalls.
      
      This flag needs some simple driver support. If the driver does not
      support this, the Rx flag is always zero and the Tx flag is always
      one. This makes any application relying on this feature default to the
      old behaviour of not requiring any syscalls in the Rx path and always
      having to call sendto() in the Tx path.
      
      For backwards compatibility reasons, this feature has to be explicitly
      turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
      that you always turn it on as it so far always have had a positive
      performance impact.
      
      The name and inspiration of the flag has been taken from io_uring by
      Jens Axboe. Details about this feature in io_uring can be found in
      http://kernel.dk/io_uring.pdf, section 8.3.
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Acked-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      77cd0d7b
  8. 28 6月, 2019 1 次提交
  9. 26 6月, 2019 1 次提交
  10. 17 4月, 2019 1 次提交
    • M
      xsk: fix XDP socket ring buffer memory ordering · f63666de
      Magnus Karlsson 提交于
      The ring buffer code of XDP sockets is missing a memory barrier on the
      consumer side between the load of the data and the write that signals
      that it is ok for the producer to put new data into the buffer. On
      architectures that does not guarantee that stores are not reordered
      with older loads, the producer might put data into the ring before the
      consumer had the chance to read it. As IA does guarantee this
      ordering, it would only need a compiler barrier here, but there are no
      primitives in Linux for this specific case (hinder writes to be ordered
      before older reads) so I had to add a smp_mb() here which will
      translate into a run-time synch operation on IA.
      
      Added a longish comment in the code explaining what each barrier in
      the ring implementation accomplishes and what would happen if we
      removed one of them.
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      f63666de
  11. 09 3月, 2019 1 次提交
    • B
      xsk: fix to reject invalid options in Tx descriptor · c57b557b
      Björn Töpel 提交于
      Passing a non-existing option in the options member of struct
      xdp_desc was, incorrectly, silently ignored. This patch addresses
      that behavior, and drops any Tx descriptor with non-existing options.
      
      We have examined existing user space code, and to our best knowledge,
      no one is relying on the current incorrect behavior. AF_XDP is still
      in its infancy, so from our perspective, the risk of breakage is very
      low, and addressing this problem now is important.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      c57b557b
  12. 26 9月, 2018 1 次提交
  13. 01 9月, 2018 1 次提交
  14. 26 7月, 2018 1 次提交
  15. 03 7月, 2018 1 次提交
  16. 05 6月, 2018 2 次提交
  17. 04 6月, 2018 2 次提交
    • B
      xsk: new descriptor addressing scheme · bbff2f32
      Björn Töpel 提交于
      Currently, AF_XDP only supports a fixed frame-size memory scheme where
      each frame is referenced via an index (idx). A user passes the frame
      index to the kernel, and the kernel acts upon the data.  Some NICs,
      however, do not have a fixed frame-size model, instead they have a
      model where a memory window is passed to the hardware and multiple
      frames are filled into that window (referred to as the "type-writer"
      model).
      
      By changing the descriptor format from the current frame index
      addressing scheme, AF_XDP can in the future be extended to support
      these kinds of NICs.
      
      In the index-based model, an idx refers to a frame of size
      frame_size. Addressing a frame in the UMEM is done by offseting the
      UMEM starting address by a global offset, idx * frame_size + offset.
      Communicating via the fill- and completion-rings are done by means of
      idx.
      
      In this commit, the idx is removed in favor of an address (addr),
      which is a relative address ranging over the UMEM. To convert an
      idx-based address to the new addr is simply: addr = idx * frame_size +
      offset.
      
      We also stop referring to the UMEM "frame" as a frame. Instead it is
      simply called a chunk.
      
      To transfer ownership of a chunk to the kernel, the addr of the chunk
      is passed in the fill-ring. Note, that the kernel will mask addr to
      make it chunk aligned, so there is no need for userspace to do
      that. E.g., for a chunk size of 2k, passing an addr of 2048, 2050 or
      3000 to the fill-ring will refer to the same chunk.
      
      On the completion-ring, the addr will match that of the Tx descriptor,
      passed to the kernel.
      
      Changing the descriptor format to use chunks/addr will allow for
      future changes to move to a type-writer based model, where multiple
      frames can reside in one chunk. In this model passing one single chunk
      into the fill-ring, would potentially result in multiple Rx
      descriptors.
      
      This commit changes the uapi of AF_XDP sockets, and updates the
      documentation.
      Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      bbff2f32
    • B
      xsk: proper fill queue descriptor validation · 4e64c835
      Björn Töpel 提交于
      Previously the fill queue descriptor was not copied to kernel space
      prior validating it, making it possible for userland to change the
      descriptor post-kernel-validation.
      Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      4e64c835
  18. 22 5月, 2018 1 次提交
    • B
      xsk: remove explicit ring structure from uapi · b3a9e0be
      Björn Töpel 提交于
      In this commit we remove the explicit ring structure from the the
      uapi. It is tricky for an uapi to depend on a certain L1 cache line
      size, since it can differ for variants of the same architecture. Now,
      we let the user application determine the offsets of the producer,
      consumer and descriptors by asking the socket via getsockopt.
      
      A typical flow would be (Rx ring):
      
        struct xdp_mmap_offsets off;
        struct xdp_desc *ring;
        u32 *prod, *cons;
        void *map;
        ...
      
        getsockopt(fd, SOL_XDP, XDP_MMAP_OFFSETS, &off, &optlen);
      
        map = mmap(NULL, off.rx.desc +
      		   NUM_DESCS * sizeof(struct xdp_desc),
      		   PROT_READ | PROT_WRITE,
      		   MAP_SHARED | MAP_POPULATE, sfd,
      		   XDP_PGOFF_RX_RING);
        prod = map + off.rx.producer;
        cons = map + off.rx.consumer;
        ring = map + off.rx.desc;
      Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      b3a9e0be
  19. 18 5月, 2018 2 次提交
  20. 04 5月, 2018 7 次提交
  21. 30 11月, 2017 1 次提交
    • M
      media: atomisp: stop producing hundreds of kernel-doc warnings · d929fb4e
      Mauro Carvalho Chehab 提交于
      A recent change on Kernel 4.15-rc1 causes all tags with
      /** to be handled as kernel-doc markups. Well, several
      atomisp modules, it doesn't use kernel-doc, but some other
      documentation markup (doxygen?).
      
      So, suppress all those warns by:
      	- replacing /**< by /**.
      	- replacing /** by /*.
      
      The core changes were done with:
      
      	for i in $(find drivers/staging/media/atomisp -type f); do sed 's,/\*\* ,/\*, ' -i $i; done
      	for i in $(find drivers/staging/media/atomisp -type f); do sed 's,/\*\*<,/\**,' -i $i; done
      	for i in drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr_vbuf.c; do perl -ne 's,\/\*\*$,/*,g; print $_'  $i > a && mv a $i; done;
      
      A few manual adjustments were made, where needed.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
      d929fb4e
  22. 06 3月, 2017 1 次提交
    • A
      staging/atomisp: Add support for the Intel IPU v2 · a49d2536
      Alan Cox 提交于
      This patch adds support for the Intel IPU v2 as found on Android and IoT
      Baytrail-T and Baytrail-CR platforms (those with the IPU PCI mapped). You
      will also need the firmware files from your device (Android usually puts
      them into /etc) - or you can find them in the downloadable restore/upgrade
      kits if you blew them away for some reason.
      
      It may be possible to extend the driver to handle the BYT/T windows
      platforms such as the ASUS T100TA. These platforms don't expose the IPU via
      the PCI interface but via ACPI buried in the GPU description and with the
      camera information somewhere unknown so would need a platform driver
      interface adding to the codebase *IFF* the firmware works on such devices.
      
      To get good results you also need a suitable support library such as
      libxcam. The camera is intended to be driven from Android so it has a lot of
      features that many desktop apps don't fully spport.
      
      In theory all the pieces are there to build it with -DISP2401 and some
      differing files to get CherryTrail/T support, but unifying the drivers
      properlly is a work in progress.
      
      The IPU driver represents the work of a lot of people within Intel over many
      years. It's historical goal was portability rather than Linux upstream. Any
      queries about the upstream aimed driver should be sent to me not to the
      original authors.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a49d2536