CVS commit: src/sys/dev/pci/ixgbe

["SAITOH Masanobu" <msaitoh%netbsd.org@localhost>]

Module Name:    src
Committed By:   msaitoh
Date:           Mon Jun  4 02:42:23 UTC 2018

Modified Files:
        src/sys/dev/pci/ixgbe: ixgbe.c ixv.c

Log Message:
 Don't call ixgbe_rearm_queues() in ixgbe_local_timer1().

   ixgbe_enable_queue() and ixgbe_disable_queue() try to enable/disable queue
  interrupt safely. It has the internal counter. When a queue's MSI-X is
  received, ixgbe_msix_que() is called (IPL_NET). This function disable the
  queue's interrupt by ixgbe_disable_queue() and issues an softint.
  ixgbe_handle() queue is called by the softint (IPL_SOFTNET), process TX, RX
  and call ixgbe_enable_queue() at the end.

   ixgbe_local_timer1() is a callout and run always on CPU 0 (IPL_SOFTCLOCK).
  When ixgbe_rearm_queues() called, an MSI-X interrupt is issued for a specific
  queue. It may not CPU 0. If this interrupt's ixgbe_msix_que() is called and
  sofint_schedule() is called before the last sofint's softint_execute() is not
  called, the softint_schedule() fails because of SOFTINT_PENDING. It result
  in breaking ixgbe_{enable,disable}_queue()'s internal counter.

   ixgbe_local_timer1() is written not to call ixgbe_rearm_queues() if
  the interrupt is disabled, but it's called because of unknown bug or a race.
  One solution to avoid this problem is to not to use the internal counter,
  but it's little difficult. Another solution is stop using
  ixgbe_rearm_queues() at all. Essentially, ixgbe_rearm_queues() is not
  required (it was added in ixgbe.c rev. 1.43 (2016/12/01)).
  ixgbe_rearm_queues() helps for lost interrupt problem but I've never seen it
  other than ixgbe_rearm_queues() problem.

XXX pullup-8.


To generate a diff of this commit:
cvs rdiff -u -r1.159 -r1.160 src/sys/dev/pci/ixgbe/ixgbe.c
cvs rdiff -u -r1.103 -r1.104 src/sys/dev/pci/ixgbe/ixv.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.