1. 27 9月, 2018 1 次提交
  2. 31 7月, 2018 2 次提交
  3. 10 7月, 2018 1 次提交
  4. 19 6月, 2018 1 次提交
  5. 09 5月, 2018 1 次提交
    • A
      nvmet,rxe: defer ip datagram sending to tasklet · 1661d3b0
      Alexandru Moise 提交于
      This addresses 3 separate problems:
      
      1. When using NVME over Fabrics we may end up sending IP
      packets in interrupt context, we should defer this work
      to a tasklet.
      
      [   50.939957] WARNING: CPU: 3 PID: 0 at kernel/softirq.c:161 __local_bh_enable_ip+0x1f/0xa0
      [   50.942602] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G        W         4.17.0-rc3-ARCH+ #104
      [   50.945466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
      [   50.948163] RIP: 0010:__local_bh_enable_ip+0x1f/0xa0
      [   50.949631] RSP: 0018:ffff88009c183900 EFLAGS: 00010006
      [   50.951029] RAX: 0000000080010403 RBX: 0000000000000200 RCX: 0000000000000001
      [   50.952636] RDX: 0000000000000000 RSI: 0000000000000200 RDI: ffffffff817e04ec
      [   50.954278] RBP: ffff88009c183910 R08: 0000000000000001 R09: 0000000000000614
      [   50.956000] R10: ffffea00021d5500 R11: 0000000000000001 R12: ffffffff817e04ec
      [   50.957779] R13: 0000000000000000 R14: ffff88009566f400 R15: ffff8800956c7000
      [   50.959402] FS:  0000000000000000(0000) GS:ffff88009c180000(0000) knlGS:0000000000000000
      [   50.961552] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   50.963798] CR2: 000055c4ec0ccac0 CR3: 0000000002209001 CR4: 00000000000606e0
      [   50.966121] Call Trace:
      [   50.966845]  <IRQ>
      [   50.967497]  __dev_queue_xmit+0x62d/0x690
      [   50.968722]  dev_queue_xmit+0x10/0x20
      [   50.969894]  neigh_resolve_output+0x173/0x190
      [   50.971244]  ip_finish_output2+0x2b8/0x370
      [   50.972527]  ip_finish_output+0x1d2/0x220
      [   50.973785]  ? ip_finish_output+0x1d2/0x220
      [   50.975010]  ip_output+0xd4/0x100
      [   50.975903]  ip_local_out+0x3b/0x50
      [   50.976823]  rxe_send+0x74/0x120
      [   50.977702]  rxe_requester+0xe3b/0x10b0
      [   50.978881]  ? ip_local_deliver_finish+0xd1/0xe0
      [   50.980260]  rxe_do_task+0x85/0x100
      [   50.981386]  rxe_run_task+0x2f/0x40
      [   50.982470]  rxe_post_send+0x51a/0x550
      [   50.983591]  nvmet_rdma_queue_response+0x10a/0x170
      [   50.985024]  __nvmet_req_complete+0x95/0xa0
      [   50.986287]  nvmet_req_complete+0x15/0x60
      [   50.987469]  nvmet_bio_done+0x2d/0x40
      [   50.988564]  bio_endio+0x12c/0x140
      [   50.989654]  blk_update_request+0x185/0x2a0
      [   50.990947]  blk_mq_end_request+0x1e/0x80
      [   50.991997]  nvme_complete_rq+0x1cc/0x1e0
      [   50.993171]  nvme_pci_complete_rq+0x117/0x120
      [   50.994355]  __blk_mq_complete_request+0x15e/0x180
      [   50.995988]  blk_mq_complete_request+0x6f/0xa0
      [   50.997304]  nvme_process_cq+0xe0/0x1b0
      [   50.998494]  nvme_irq+0x28/0x50
      [   50.999572]  __handle_irq_event_percpu+0xa2/0x1c0
      [   51.000986]  handle_irq_event_percpu+0x32/0x80
      [   51.002356]  handle_irq_event+0x3c/0x60
      [   51.003463]  handle_edge_irq+0x1c9/0x200
      [   51.004473]  handle_irq+0x23/0x30
      [   51.005363]  do_IRQ+0x46/0xd0
      [   51.006182]  common_interrupt+0xf/0xf
      [   51.007129]  </IRQ>
      
      2. Work must always be offloaded to tasklet for rxe_post_send_kernel()
      when using NVMEoF in order to solve lock ordering between neigh->ha_lock
      seqlock and the nvme queue lock:
      
      [   77.833783]  Possible interrupt unsafe locking scenario:
      [   77.833783]
      [   77.835831]        CPU0                    CPU1
      [   77.837129]        ----                    ----
      [   77.838313]   lock(&(&n->ha_lock)->seqcount);
      [   77.839550]                                local_irq_disable();
      [   77.841377]                                lock(&(&nvmeq->q_lock)->rlock);
      [   77.843222]                                lock(&(&n->ha_lock)->seqcount);
      [   77.845178]   <Interrupt>
      [   77.846298]     lock(&(&nvmeq->q_lock)->rlock);
      [   77.847986]
      [   77.847986]  *** DEADLOCK ***
      
      3. Same goes for the lock ordering between sch->q.lock and nvme queue lock:
      
      [   47.634271]  Possible interrupt unsafe locking scenario:
      [   47.634271]
      [   47.636452]        CPU0                    CPU1
      [   47.637861]        ----                    ----
      [   47.639285]   lock(&(&sch->q.lock)->rlock);
      [   47.640654]                                local_irq_disable();
      [   47.642451]                                lock(&(&nvmeq->q_lock)->rlock);
      [   47.644521]                                lock(&(&sch->q.lock)->rlock);
      [   47.646480]   <Interrupt>
      [   47.647263]     lock(&(&nvmeq->q_lock)->rlock);
      [   47.648492]
      [   47.648492]  *** DEADLOCK ***
      
      Using NVMEoF after this patch seems to finally be stable, without it,
      rxe eventually deadlocks the whole system and causes RCU stalls.
      Signed-off-by: NAlexandru Moise <00moses.alexander00@gmail.com>
      Reviewed-by: NZhu Yanjun <yanjun.zhu@oracle.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      1661d3b0
  6. 28 4月, 2018 1 次提交
  7. 06 4月, 2018 2 次提交
    • M
      IB/rxe: Fix for oops in rxe_register_device on ppc64le arch · efc365e7
      Mikhail Malygin 提交于
      On ppc64le arch rxe_add command causes oops in kernel log:
      
      [   92.495140] Oops: Kernel access of bad area, sig: 11 [#1]
      [   92.499710] SMP NR_CPUS=2048 NUMA pSeries
      [   92.499792] Modules linked in: ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) nf_conntrack_netlink(E) nfnetlink(E) xfrm_user(E) iptable
      _nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) xt_addrtype(E) iptable_filter(E) ip_tables(E) xt_conntrack(E) x_tables(E)
       nf_nat(E) nf_conntrack(E) br_netfilter(E) bridge(E) stp(E) llc(E) overlay(E) af_packet(E) rpcrdma(E) ib_isert(E) iscsi_target_mod(E) i
      b_iser(E) libiscsi(E) ib_srpt(E) target_core_mod(E) ib_srp(E) ib_ipoib(E) rdma_ucm(E) ib_ucm(E) ib_uverbs(E) ib_umad(E) bochs_drm(E) tt
      m(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) drm(E) agpgart(E) virtio_rng(E) virtio_console(E) rtc_
      generic(E) dm_ec(OEN) ttln_rdma(OEN) rdma_cm(E) configfs(E) iw_cm(E) ib_cm(E) rdma_rxe(E) ip6_udp_tunnel(E) udp_tunnel(E) ib_core(E) ql
      a2xxx(E)
      [   92.499832]  scsi_transport_fc(E) nvme_fc(E) nvme_fabrics(E) nvme_core(E) ipmi_watchdog(E) ipmi_ssif(E) ipmi_poweroff(E) ipmi_powernv(EX) ipmi_devintf(E) ipmi_msghandler(E) dummy(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_service_time(E) scsi_transport_iscsi(E) sd_mod(E) sr_mod(E) cdrom(E) hid_generic(E) usbhid(E) virtio_blk(E) virtio_scsi(E) virtio_net(E) ibmvscsi(EX) scsi_transport_srp(E) xhci_pci(E) xhci_hcd(E) usbcore(E) usb_common(E) virtio_pci(E) virtio_ring(E) virtio(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E)
      [   92.499834] Supported: No, Unsupported modules are loaded
      [   92.499839] CPU: 3 PID: 5576 Comm: sh Tainted: G           OE   NX 4.4.120-ttln.17-default #1
      [   92.499841] task: c0000000afe8a490 ti: c0000000beba8000 task.ti: c0000000beba8000
      [   92.499842] NIP: c00000000008ba3c LR: c000000000027644 CTR: c00000000008ba10
      [   92.499844] REGS: c0000000bebab750 TRAP: 0300   Tainted: G           OE   NX  (4.4.120-ttln.17-default)
      [   92.499850] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 28424428  XER: 20000000
      [   92.499871] CFAR: 0000000000002424 DAR: 0000000000000208 DSISR: 40000000 SOFTE: 1
                     GPR00: c000000000027644 c0000000bebab9d0 c000000000f09700 0000000000000000
                     GPR04: d0000000043d7192 0000000000000002 000000000000001a fffffffffffffffe
                     GPR08: 000000000000009c c00000000008ba10 d0000000043e5848 d0000000043d3828
                     GPR12: c00000000008ba10 c000000007a02400 0000000010062e38 0000010020388860
                     GPR16: 0000000000000000 0000000000000000 00000100203885f0 00000000100f6c98
                     GPR20: c0000000b3f1fcc0 c0000000b3f1fc48 c0000000b3f1fbd0 c0000000b3f1fb58
                     GPR24: c0000000b3f1fae0 c0000000b3f1fa68 00000000000005dc c0000000b3f1f9f0
                     GPR28: d0000000043e5848 c0000000b3f1f900 c0000000b3f1f320 c0000000b3f1f000
      [   92.499881] NIP [c00000000008ba3c] dma_get_required_mask_pSeriesLP+0x2c/0x1a0
      [   92.499885] LR [c000000000027644] dma_get_required_mask+0x44/0xac
      [   92.499886] Call Trace:
      [   92.499891] [c0000000bebab9d0] [c0000000bebaba30] 0xc0000000bebaba30 (unreliable)
      [   92.499894] [c0000000bebaba10] [c000000000027644] dma_get_required_mask+0x44/0xac
      [   92.499904] [c0000000bebaba30] [d0000000043cb4b4] rxe_register_device+0xc4/0x430 [rdma_rxe]
      [   92.499910] [c0000000bebabab0] [d0000000043c06c8] rxe_add+0x448/0x4e0 [rdma_rxe]
      [   92.499915] [c0000000bebabb30] [d0000000043d28dc] rxe_net_add+0x4c/0xf0 [rdma_rxe]
      [   92.499921] [c0000000bebabb60] [d0000000043d305c] rxe_param_set_add+0x6c/0x1ac [rdma_rxe]
      [   92.499924] [c0000000bebabbf0] [c0000000000e78c0] param_attr_store+0xa0/0x180
      [   92.499927] [c0000000bebabc70] [c0000000000e6448] module_attr_store+0x48/0x70
      [   92.499932] [c0000000bebabc90] [c000000000391f60] sysfs_kf_write+0x70/0xb0
      [   92.499935] [c0000000bebabcb0] [c000000000390f1c] kernfs_fop_write+0x18c/0x1e0
      [   92.499939] [c0000000bebabd00] [c0000000002e22ac] __vfs_write+0x4c/0x1d0
      [   92.499942] [c0000000bebabd90] [c0000000002e2f94] vfs_write+0xc4/0x200
      [   92.499945] [c0000000bebabde0] [c0000000002e488c] SyS_write+0x6c/0x110
      [   92.499948] [c0000000bebabe30] [c000000000009384] system_call+0x38/0xe4
      [   92.499949] Instruction dump:
      [   92.499954] 4e800020 3c4c00e8 3842dcf0 7c0802a6 f8010010 60000000 7c0802a6 fba1ffe8
      [   92.499958] fbc1fff0 fbe1fff8 f8010010 f821ffc1 <e9230208> 7c7e1b78 2fa90000 419e0078
      [   92.499962] ---[ end trace bed077e15eb420cf ]---
      
      It fails in dma_get_required_mask, that has ppc-specific implementation,
      and fail if provided device argument is NULL
      Signed-off-by: NMikhail Malygin <mikhail@malygin.me>
      Reviewed-by: NYonatan Cohen <yonatanc@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      efc365e7
    • P
      IB/rxe: Removed GID add/del dummy routines · 39e00b6c
      Parav Pandit 提交于
      rxe driver's add_gid() and del_gid() callbacks are doing simple
      checks which are already done by the ib core before invoking these
      callback routines.
      Therefore, code is simplified to skip implementing add_gid() and
      del_gid() callback functions.
      They are only invoked by ib_core if they are implemented.
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      39e00b6c
  8. 04 4月, 2018 3 次提交
  9. 20 3月, 2018 1 次提交
  10. 16 3月, 2018 2 次提交
  11. 07 3月, 2018 1 次提交
    • B
      RDMA/rxe: Fix an out-of-bounds read · a6544a62
      Bart Van Assche 提交于
      This patch avoids that KASAN reports the following when the SRP initiator
      calls srp_post_send():
      
      ==================================================================
      BUG: KASAN: stack-out-of-bounds in rxe_post_send+0x5c4/0x980 [rdma_rxe]
      Read of size 8 at addr ffff880066606e30 by task 02-mq/1074
      
      CPU: 2 PID: 1074 Comm: 02-mq Not tainted 4.16.0-rc3-dbg+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
      Call Trace:
      dump_stack+0x85/0xc7
      print_address_description+0x65/0x270
      kasan_report+0x231/0x350
      rxe_post_send+0x5c4/0x980 [rdma_rxe]
      srp_post_send.isra.16+0x149/0x190 [ib_srp]
      srp_queuecommand+0x94d/0x1670 [ib_srp]
      scsi_dispatch_cmd+0x1c2/0x550 [scsi_mod]
      scsi_queue_rq+0x843/0xa70 [scsi_mod]
      blk_mq_dispatch_rq_list+0x143/0xac0
      blk_mq_do_dispatch_ctx+0x1c5/0x260
      blk_mq_sched_dispatch_requests+0x2bf/0x2f0
      __blk_mq_run_hw_queue+0xdb/0x160
      __blk_mq_delay_run_hw_queue+0xba/0x100
      blk_mq_run_hw_queue+0xf2/0x190
      blk_mq_sched_insert_request+0x163/0x2f0
      blk_execute_rq+0xb0/0x130
      scsi_execute+0x14e/0x260 [scsi_mod]
      scsi_probe_and_add_lun+0x366/0x13d0 [scsi_mod]
      __scsi_scan_target+0x18a/0x810 [scsi_mod]
      scsi_scan_target+0x11e/0x130 [scsi_mod]
      srp_create_target+0x1522/0x19e0 [ib_srp]
      kernfs_fop_write+0x180/0x210
      __vfs_write+0xb1/0x2e0
      vfs_write+0xf6/0x250
      SyS_write+0x99/0x110
      do_syscall_64+0xee/0x2b0
      entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      The buggy address belongs to the page:
      page:ffffea0001998180 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0x4000000000000000()
      raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff
      raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
      ffff880066606d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1
      ffff880066606d80: f1 00 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2
      >ffff880066606e00: f2 00 00 00 00 00 f2 f2 f2 f3 f3 f3 f3 00 00 00
                                          ^
      ffff880066606e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ffff880066606f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Signed-off-by: NBart Van Assche <bart.vanassche@wdc.com>
      Cc: Moni Shoua <monis@mellanox.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      a6544a62
  12. 01 2月, 2018 5 次提交
  13. 11 1月, 2018 1 次提交
    • B
      RDMA/rxe: Fix a race condition related to the QP error state · 6f301e06
      Bart Van Assche 提交于
      The following sequence:
      * Change queue pair state into IB_QPS_ERR.
      * Post a work request on the queue pair.
      
      Triggers the following race condition in the rdma_rxe driver:
      * rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function
        that examines the QP send queue.
      * rxe_post_send() posts a work request on the QP send queue.
      
      If rxe_completer() runs prior to rxe_post_send(), it will drain the send
      queue and the driver will assume no further action is necessary.
      However, once we post the send to the send queue, because the queue is
      in error, no send completion will ever happen and the send will get
      stuck.  In order to process the send, we need to make sure that
      rxe_completer() gets run after a send is posted to a queue pair in an
      error state.  This patch ensures that happens.
      Signed-off-by: NBart Van Assche <bart.vanassche@wdc.com>
      Cc: Moni Shoua <monis@mellanox.com>
      Cc: <stable@vger.kernel.org> # v4.8
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      6f301e06
  14. 11 11月, 2017 1 次提交
  15. 15 10月, 2017 1 次提交
  16. 29 8月, 2017 1 次提交
    • A
      IB/rxe: Disable completion upcalls when a CQ is destroyed · bfc3ae05
      Andrew Boyer 提交于
      This prevents the stack from accessing userspace objects while they
      are being torn down.
      
      One possible sequence of events:
       - Userspace program exits
       - ib_uverbs_cleanup_ucontext() runs, calling ib_destroy_qp(),
         ib_destroy_cq(), etc. and releasing/freeing the UCQ
         - The QP still has tasklets running, so it isn't destroyed yet
         - The CQ is referenced by the QP, so the CQ isn't destroyed yet
         - The UCQ is kfree()'d anyway
       - A send work request completes
       - rxe_send_complete() calls cq->ibcq.comp_handler()
       - ib_uverbs_comp_handler() runs and crashes; the event queue is checked
         for is_closed, but it has no way to check the ib_ucq_object before
         accessing it
      
      The reference counting on the CQ doesn't protect against this since the CQ
      hasn't been destroyed yet.
      There's no available interface to deregister the UCQ from the CQ, and it
      didn't appear that attempting to add reference counting to the UCQ was
      going to be a good way to go since this solution is much simpler.
      
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Signed-off-by: NAndrew Boyer <andrew.boyer@dell.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      bfc3ae05
  17. 24 7月, 2017 3 次提交
  18. 20 7月, 2017 1 次提交
  19. 18 7月, 2017 1 次提交
    • Y
      IB/rxe: Set dma_mask and coherent_dma_mask · 56012e1c
      yonatanc 提交于
      The RXE coupled with dummy device causes to the kernel panic attached
      below.  The panic happens when ib_register_device tries to set dma_mask
      by accessing a NULLed parent device.
      
      The RXE does not actually use DMA, so we can set the dma_mask
      to architecture value.
      
      [16240.199689] RIP: 0010:ib_register_device+0x468/0x5a0 [ib_core]
      [16240.205289] RSP: 0018:ffffc9000220fc10 EFLAGS: 00010246
      [16240.209909] RAX: 0000000000000024 RBX: ffff880220d1a2a8 RCX: 0000000000000000
      [16240.212244] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000009
      [16240.214385] RBP: ffffc9000220fcb0 R08: 0000000000000000 R09: 000000000000023f
      [16240.254465] R10: 0000000000000007 R11: 0000000000000000 R12: 0000000000000000
      [16240.259467] R13: 0000000000000000 R14: 0000000000000000 R15: ffff880220d1a2a8
      [16240.263314] FS:  00007fd8ecca0740(0000) GS:ffff8802364c0000(0000) knlGS:0000000000000000
      [16240.267292] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [16240.273503] CR2: 0000000000000218 CR3: 00000002253ba000 CR4: 00000000000006e0
      [16240.277066] Call Trace:
      [16240.281836]  ? __kmalloc+0x26f/0x280
      [16240.286596]  rxe_register_device+0x297/0x300 [rdma_rxe]
      [16240.291377]  rxe_add+0x535/0x5b0 [rdma_rxe]
      [16240.297586]  rxe_net_add+0x3e/0xc0 [rdma_rxe]
      [16240.302375]  rxe_param_set_add+0x65/0x144 [rdma_rxe]
      [16240.307769]  param_attr_store+0x68/0xd0
      [16240.311640]  module_attr_store+0x1d/0x30
      [16240.316421]  sysfs_kf_write+0x3a/0x50
      [16240.317802]  kernfs_fop_write+0xff/0x180
      [16240.322989]  __vfs_write+0x37/0x140
      [16240.328164]  ? handle_mm_fault+0xce/0x240
      [16240.333340]  vfs_write+0xb2/0x1b0
      [16240.335013]  SyS_write+0x55/0xc0
      [16240.340632]  entry_SYSCALL_64_fastpath+0x1a/0xa9
      
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Signed-off-by: NYonatan Cohen <yonatanc@mellanox.com>
      Reviewed-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      56012e1c
  20. 15 6月, 2017 1 次提交
  21. 05 5月, 2017 1 次提交
  22. 02 5月, 2017 4 次提交
  23. 29 4月, 2017 1 次提交
  24. 26 4月, 2017 1 次提交
  25. 21 4月, 2017 2 次提交
    • Y
      IB/rxe: Offload CRC calculation when possible · cee2688e
      yonatanc 提交于
      Use CPU ability to perform CRC calculations, by
      replacing direct calls to crc32_le() with crypto_shash_updata().
      
      The overall performance gain measured with ib_send_bw tool is 10% and it
      was tested on "Intel CPU ES-2660 v2 @ 2.20Ghz" CPU.
      
      ib_send_bw -d rxe0  -x 1 -n 9000 -e  -s $((1024 * 1024 )) -l 100
      
      ---------------------------------------------------------------------------------------------
      |             | bytes   | iterations | BW peak[MB/sec] | BW average[MB/sec] | MsgRate[Mpps] |
      ---------------------------------------------------------------------------------------------
      | crc32_le    | 1048576 | 9000       | inf             | 497.60             | 0.000498      |
      | CRC offload | 1048576 | 9000       | inf             | 546.70             | 0.000547      |
      ---------------------------------------------------------------------------------------------
      
      Fixes: 8700e3e7 ("Soft RoCE driver")
      Signed-off-by: NYonatan Cohen <yonatanc@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      cee2688e
    • Y
      IB/rxe: Add port protocol stats · 0b1e5b99
      Yonatan Cohen 提交于
      Expose new counters using the get_hw_stats callback.
      We expose the following counters:
      
      +---------------------+----------------------------------------+
      |      Name           |           Description                  |
      |---------------------+----------------------------------------|
      |sent_pkts            | number of sent pkts                    |
      |---------------------+----------------------------------------|
      |rcvd_pkts            | number of received packets             |
      |---------------------+----------------------------------------|
      |out_of_sequence      | number of errors due to packet         |
      |                     | transport sequence number              |
      |---------------------+----------------------------------------|
      |duplicate_request    | number of received duplicated packets. |
      |                     | A request that previously executed is  |
      |                     | named duplicated.                      |
      |---------------------+----------------------------------------|
      |rcvd_rnr_err         | number of received RNR by completer    |
      |---------------------+----------------------------------------|
      |send_rnr_err         | number of sent RNR by responder        |
      |---------------------+----------------------------------------|
      |rcvd_seq_err         | number of out of sequence packets      |
      |                     | received                               |
      |---------------------+----------------------------------------|
      |ack_deffered         | number of deferred handling of ack     |
      |                     | packets.                               |
      |---------------------+----------------------------------------|
      |retry_exceeded_err   | number of times retry exceeded         |
      |---------------------+----------------------------------------|
      |completer_retry_err  | number of times completer decided to   |
      |                     | retry                                  |
      |---------------------+----------------------------------------|
      |send_err             | number of failed send packet           |
      +---------------------+----------------------------------------+
      Signed-off-by: NYonatan Cohen <yonatanc@mellanox.com>
      Reviewed-by: NMoni Shoua <monis@mellanox.com>
      Reviewed-by: NAndrew Boyer <andrew.boyer@dell.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      0b1e5b99