Skip to content
  1. May 25, 2016
  2. May 18, 2016
    • Matan Barak's avatar
      IB/mlx5: Fire the CQ completion handler from tasklet · c16d2750
      Matan Barak authored
      
      
      Previously, mlx5_ib_cq_comp was executed from interrupt context.
      Under heavy load, this could cause the CPU core to be in an interrupt
      context too long.
      Instead of executing the handler from the interrupt context we
      execute it from a much friendly tasklet context.
      
      Signed-off-by: default avatarMatan Barak <matanb@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      c16d2750
    • Matan Barak's avatar
      net/mlx5_core: Use tasklet for user-space CQ completion events · 94c6825e
      Matan Barak authored
      
      
      Previously, we've fired all our completion callbacks straight from
      our ISR.
      
      Some of those callbacks were lightweight (for example, mlx5 Ethernet
      napi callbacks), but some of them did more work (for example,
      the user-space RDMA stack uverbs' completion handler). Besides that,
      doing more than the minimal work in ISR is generally considered wrong,
      it could even lead to a hard lockup of the system. Since when a lot
      of completion events are generated by the hardware, the loop over
      those events could be so long, that we'll get into a hard lockup by
      the system watchdog.
      
      In order to avoid that, add a new way of invoking completion events
      callbacks. In the interrupt itself, we add the CQs which receive
      completion event to a per-EQ list and schedule a tasklet. In the
      tasklet context we loop over all the CQs in the list and invoke the
      user callback.
      
      Signed-off-by: default avatarMatan Barak <matanb@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      94c6825e
    • Christoph Lameter's avatar
      IB/core: Do not require CAP_NET_ADMIN for packet sniffing · e3b6d8cf
      Christoph Lameter authored
      
      
      In the Ethernet/TCP world, CAP_NET_RAW is sufficient to allow a program
      to listen to all incoming packets on a specific interface, and the
      higher CAP_NET_ADMIN is required to set the interface into promiscuous
      mode.  We want to emulate that same basic division of privilege in the
      RDMA stack, so when dealing with Raw Ethernet QPs, allow apps with
      CAP_NET_RAW to listen to all incoming flows (and direct them as they see
      fit in their own listen stream).  Do not require CAP_NET_ADMIN just to
      listen to traffic already incoming.  Reserve CAP_NET_ADMIN if we attempt
      to set promiscuous mode.
      
      Signed-off-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      e3b6d8cf
    • shamir rabinovitch's avatar
      IB/mlx4: Fix unaligned access in send_reply_to_slave · 04ef0f1a
      shamir rabinovitch authored
      The problem is that the function 'send_reply_to_slave' gets the
      'req_sa_mad' as a pointer whose address is only aliged to 4 bytes
      but is 8 bytes in size.  This can result in unaligned access faults
      on certain architectures.
      
      Sowmini Varadhan pointed to this reply from Dave Miller that say
      that memcpy should not be used to solve alignment issues:
      https://lkml.org/lkml/2015/10/21/352
      
      
      
      Optimization of memcpy to 'ldx' instruction can only happen if the
      compiler knows that the size of the data we are copying is 8 bytes
      and it assumes it is aligned to 8 bytes. If the compiler know the
      type is not aligned to 8 it must not optimize the 8 byte copy.
      Defining the data type as aligned to 4 forces the compiler to treat
      all accesses as though they aren't aligned and avoids the 'ldx'
      optimization.
      
      Full credit for the idea goes to Jason Gunthorpe
      <jgunthorpe@obsidianresearch.com>.
      
      Signed-off-by: default avatarShamir Rabinovitch <shamir.rabinovitch@oracle.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      04ef0f1a
  3. May 14, 2016