CVS commit: [netbsd-8] src/sys/dev/pci/ixgbe

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Mon Feb 26 13:55:54 UTC 2018

Modified Files:
        src/sys/dev/pci/ixgbe [netbsd-8]: ix_txrx.c ixgbe.c ixgbe.h
            ixgbe_type.h ixv.c

Log Message:
Pull up following revision(s) (requested by msaitoh in ticket #592):
        sys/dev/pci/ixgbe/ixv.c: revision 1.79
        sys/dev/pci/ixgbe/ixgbe.h: revision 1.30
        sys/dev/pci/ixgbe/ix_txrx.c: revision 1.31
        sys/dev/pci/ixgbe/ix_txrx.c: revision 1.32
        sys/dev/pci/ixgbe/ixgbe_type.h: revision 1.31
        sys/dev/pci/ixgbe/ixgbe.c: revision 1.120
        sys/dev/pci/ixgbe/ixgbe.c: revision 1.121
        sys/dev/pci/ixgbe/ixgbe.c: revision 1.123
        sys/dev/pci/ixgbe/ixgbe.c: revision 1.124
        sys/dev/pci/ixgbe/ixgbe.c: revision 1.125
        sys/dev/pci/ixgbe/ixgbe.c: revision 1.126
        sys/dev/pci/ixgbe/ixv.c: revision 1.80
        sys/dev/pci/ixgbe/ixv.c: revision 1.81
 CID-1427719: Integer handling issues  (BAD_SHIFT). Print bus/slot info
correctly on 82599_SFP_SF_QP(DID 0x154a) and 82599_QSFP_SF_QP(DID 0x1558).
 Fix a bug that RX may stall on heavy load on ixg(4). ixgbe_rxeof() has loop
limit and the function returns true if a packet are still in the RX ring.
ixgbe_handle_que() didn't check the return value. Check the return vaule
and issue a softint.
 This bug is derived from FreeBSD and ixv(4) has no this bug.
XXX pullup-8
 Fix a bug that the first call of ifflags_cb() causes linkdown. The first
call of ix(gbe|v)_ifflags_cb() refered uninitialized adapter->if_flags.
adapter->if_flags should be initialized in the end of xxx_init().
XXX pullup-[678] (ixgbe)
XXX pullup-8 (ixv)
- Fix a bug that RX may stall on heavy load on ixg(4) derived from FreeBSD's
 AIM (Auto Interrupt Moderation) bug.
 When I use a machine as a NFS client, sometimes one of queue pairs doesn't
 get any interrupt other than every second tick via ixgbe_local_timer1().
 When the problem occured, the queue pair's hw.ixgM.qN.interrupt_rate is
 always 500000. When this problem occuring, set hw.ixgM.qN.interrupt_rate lower
 than 166667 recover from stall. i.e.:
  sysctl -w hw.ixgM.qN.interrupt_rate=166667 (don't revocer)
  sysctl -w hw.ixgM.qN.interrupt_rate=166666 (recover)
  Relatios between the interrupt_rate and EICR's ITR_INTERVAL field is as
 follows:
 int_rate | EICR[11:0]   | interval in us | recover |
          |(ITR_INTERVAL)| (10G and 1G)   |         |
 ---------+--------------+----------------+---------+
   500000 | 0x008(0)     |              2 |     not |
   166667 | 0x010(1)     |              4 |     not |
   166666 | 0x018(2)     |              6 | recover |
  The reason why int_rate becomes 500000 is that xgbe_tx_eof() doesn't
 increment rxr->packets(*1). Even if we fix rxr->packets' bug, interrupt_rate
 might become greater than 166666 and it might cause stall.
  While reading datasheets, knakahara noticed a section titled with "ITR
 Affect on RSC Functionality". It says "When RSC is enabled on specific RX
 queues, the associated ITR interval with these queus must be enabled and must
 be larger (in time uints) than RSC delay". Currently, RSC_DELAY field in the
 GPIE register is 0 and it means 4us for 10G and 1G. The greater ITR_INTERVAL
 value of 4us is 6us == 166666. Yes, BINGO!
  This description is noted in 82599 and newer datasheets and not in 82598
 datasheet. I don't know if 82598 has this limitation but, I apply this
 limitation all of chips.
 (*1) Note that this bug is going to be fixed in the next commit to distinct
 between two different bugs.
- The bitfield of EITR register is different between 82598 and others.
 Only ixgbe_msix_que() taken care of it. Make new function ixgbe_eitr_write()
 and use it in all of functions which modify ITR_INTERVAL.
XXX pullup-8
 Increment rxr->packets correctly in ixgbe_rxeof() to calculate ITR value
of AIM (Auto Interrupt Moderation) correctly. See also ixgbe.c rev. 1.124.
XXX pullup-8
Improve a comment about reading EICS register defined write-only by spec.
It seems that is workaround for silicon errata.
ok by msaitoh@n.o.
- Apply ixgbe.c rev. 1.124 to ixv.c. Fix a bug that RX may stall on heavy load
 on ixv(4) derived from FreeBSD's AIM (Auto Interrupt Moderation) bug.
 ITR_INTERVAL value must be larger than 4us.
- The bitfield of EITR register is different between 82598 and others.
 ixv.c had a bug that it accessed 82598's way even though only 82599 and
 newer support virtual function. Fix it using with new ixv_eitr_write()
 function.
 Fix a potential bug that TX/RX might stall when TX rate limit reached.
This change is almost the same as the RX rate limit bug fix in ixgbe.c
rev. 1.121. I've never got any stall, but this must be a bug.


To generate a diff of this commit:
cvs rdiff -u -r1.24.2.3 -r1.24.2.4 src/sys/dev/pci/ixgbe/ix_txrx.c
cvs rdiff -u -r1.88.2.9 -r1.88.2.10 src/sys/dev/pci/ixgbe/ixgbe.c
cvs rdiff -u -r1.24.6.2 -r1.24.6.3 src/sys/dev/pci/ixgbe/ixgbe.h
cvs rdiff -u -r1.22.2.2 -r1.22.2.3 src/sys/dev/pci/ixgbe/ixgbe_type.h
cvs rdiff -u -r1.56.2.6 -r1.56.2.7 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.