Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 31 3月, 2018 1 次提交
    • R
      liquidio: prevent rx queues from getting stalled · ccdd0b4c
      由 Raghu Vatsavayi 提交于 
      This commit has fix for RX traffic issues when we stress test the driver
with continuous ifconfig up/down under very high traffic conditions.

Reason for the issue is that, in existing liquidio_stop function NAPI is
disabled even before actual FW/HW interface is brought down via
send_rx_ctrl_cmd(lio, 0). Between time frame of NAPI disable and actual
interface down in firmware, firmware continuously enqueues rx traffic to
host. When interrupt happens for new packets, host irq handler fails in
scheduling NAPI as the NAPI is already disabled.

After "ifconfig <iface> up", Host re-enables NAPI but cannot schedule it
until it receives another Rx interrupt. Host never receives Rx interrupt as
it never cleared the Rx interrupt it received during interface down
operation. NIC Rx interrupt gets cleared only when Host processes queue and
clears the queue counts. Above anomaly leads to other issues like packet
overflow in FW/HW queues, backpressure.

Fix:
This commit fixes this issue by disabling NAPI only after informing
firmware to stop queueing packets to host via send_rx_ctrl_cmd(lio, 0).
send_rx_ctrl_cmd is not visible in the patch as it is already there in the
code. The DOWN command also waits for any pending packets to be processed
by NAPI so that the deadlock will not occur.
Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@cavium.com>
Acked-by: NDerek Chickles <derek.chickles@cavium.com>
Signed-off-by: NFelix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ccdd0b4c
  3. 27 3月, 2018 1 次提交
  5. 26 3月, 2018 12 次提交
  7. 12 3月, 2018 1 次提交
  9. 28 10月, 2017 1 次提交
    • F
      liquidio: fix kernel panic in VF driver · aa28667c
      由 Felix Manlunas 提交于 
      Doing ifconfig down on VF driver in the middle of receiving line rate
traffic causes a kernel panic:

    LiquidIO_VF 0000:02:00.3: should not come here should not get rx when poll mode = 0 for vf
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    .
    .
    .
    Call Trace:
     <IRQ>
     ? tasklet_action+0x102/0x120
     __do_softirq+0x91/0x292
     irq_exit+0xb6/0xc0
     do_IRQ+0x4f/0xd0
     common_interrupt+0x93/0x93
     </IRQ>
    RIP: 0010:cpuidle_enter_state+0x142/0x2f0
    RSP: 0018:ffffffffa6403e20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff59
    RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000001f
    RDX: 0000000000000000 RSI: 000000002ab7519f RDI: 0000000000000000
    RBP: ffffffffa6403e58 R08: 0000000000000084 R09: 0000000000000018
    R10: ffffffffa6403df0 R11: 00000000000003c7 R12: 0000000000000003
    R13: ffffd27ebd806800 R14: ffffffffa64d40d8 R15: 0000007be072823f
     cpuidle_enter+0x17/0x20
     call_cpuidle+0x23/0x40
     do_idle+0x18c/0x1f0
     cpu_startup_entry+0x64/0x70
     rest_init+0xa5/0xb0
     start_kernel+0x45e/0x46b
     x86_64_start_reservations+0x24/0x26
     x86_64_start_kernel+0x6f/0x72
     secondary_startup_64+0xa5/0xa5
    Code:  Bad RIP value.
    RIP:           (null) RSP: ffff9246ed003f28
    CR2: 0000000000000000
    ---[ end trace 92731e80f31b7d7d ]---
    Kernel panic - not syncing: Fatal exception in interrupt
    Kernel Offset: 0x24000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
    ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Reason is:  in the function assigned to net_device_ops->ndo_stop, the steps
for bringing down the interface are done in the wrong order.  The step that
notifies the NIC firmware to stop forwarding packets to host is done too
late.  Fix it by moving that step to the beginning.
Signed-off-by: NFelix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: NRaghu Vatsavayi <raghu.vatsavayi@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa28667c
  11. 27 10月, 2017 1 次提交
  13. 19 10月, 2017 2 次提交
  15. 23 8月, 2017 1 次提交
  17. 17 8月, 2017 1 次提交
  19. 16 8月, 2017 3 次提交
  21. 15 8月, 2017 8 次提交
  23. 10 8月, 2017 1 次提交
  25. 20 7月, 2017 1 次提交
    • G
      liquidio: lio_vf_main: remove unnecessary static in setup_io_queues() · 93fe07e5
      由 Gustavo A. R. Silva 提交于 
      Remove unnecessary static on local variables cpu_id_modulus and cpu_id.
Such variables are initialized before being used, on every execution
path throughout the function. The static has no benefit and, removing
it reduces the object file size.

This issue was detected using Coccinelle and the following semantic patch:

@bad exists@
position p;
identifier x;
type T;
@@

static T x@p;
...
x = <+...x...+>

@@
identifier x;
expression e;
type T;
position p != bad.p;
@@

-static
 T x@p;
 ... when != x
     when strict
?x = e;

In the following log you can see a significant difference in the object
file size. Also, there is a significant difference in the bss segment.
This log is the output of the size command, before and after the code
change:

before:
   text    data     bss     dec     hex filename
  55656   10680     576   66912   10560 drivers/net/ethernet/cavium/liquidio/lio_vf_main.o

after:
   text    data     bss     dec     hex filename
  55796   10536     448   66780   104dc drivers/net/ethernet/cavium/liquidio/lio_vf_main.o
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93fe07e5
  27. 19 6月, 2017 1 次提交
  29. 10 6月, 2017 1 次提交
  31. 03 6月, 2017 1 次提交
  33. 22 5月, 2017 1 次提交
  35. 17 5月, 2017 1 次提交
  37. 08 4月, 2017 1 次提交
    • F
      liquidio: fix VF incorrectly indicating that it successfully set its VLAN · 0c264588
      由 Felix Manlunas 提交于 
      For security reasons, NIC firmware does not allow VF to set its VLAN if PF
set it already.  Firmware allows VF to set its VLAN if PF did not set it.
After the VF instructs the firmware to set the VLAN, VF always indicates
(via return 0) that the operation is successful--even for the times when it
isn't.

Put in a mechanism for the VF's set VLAN function to receive the firmware
response code, then make that function return -EPERM if the firmware
forbids the operation.

Make that mechanism available for other functions that may, in the future,
be interested in receiving the response code from the firmware.  That
mechanism involves adding new fields to struct octnic_ctrl_pkt, so make all
users of struct octnic_ctrl_pkt initialize the struct to zero before using
it; otherwise, the mechanism might act on uninitialized garbage.
Signed-off-by: NFelix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: NDerek Chickles <derek.chickles@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c264588