src/sys/dev, branch upstream/10.4.0

MF10: r323830

2017-09-20T22:14:50Z

Unbreak netmap(4) support in ixgbe(4) after r315333: - Both ixgbe_netmap.c and ixv_netmap.c assumed a netmap(4) driver newer than what's actually in stable/10. - Additionally, at the bottom line ixv_netmap.c did exactly the same as ixgbe_netmap.c, i. e. used IXGBE_TDH() as appropriate for PFs only instead of IXGBE_VFTDH() and tried to configure CRC stripping although the corresponding registers aren't available to VFs in the first place. With these changes, the netmap(4) support in ixgbe(4) is in line again with the code in sys/dev/netmap/ixgbe_netmap.h as of r295008. Breakage reported by: Slawa Olhovchenkov Just like r315333 that never existed in head, this is a direct commit to stable/10. However, ixgbe(4) in head has a related bug in that it assumes a netmap(4) driver API older than what's in head and also does the wrong things for VFs as it uses the PF-only ixgbe_netmap.c for both PFs and VFs in the first place. MF10: r323835, MFC: r320916 Reset unsupported SFP tuneable back to original entry name. Approved by: re (gjb)

- Ever since the workaround for the silicon bug of TSO4 causing MAC hangs

2017-09-08T00:11:35Z

was committed in r295133 (MFCed to stable/10 in r295287), CSUM_TSO gets always disabled by em(4) on the first invocation of em_init_locked() as at that point no link is established, yet. In turn, this causes CSUM_TSO also to be off when em(4) is used as a parent device for vlan(4), i. e. besides IFCAP_TSO4, IFCAP_VLAN_HWTSO effectively doesn't work either. In head an attempt to fix this was made with r308345, but that revision had several problems on its own. One of which was that r308345 caused IFCAP_TSO4 to also be cleared from both the interface capability and capability enable bits. Thus, once a link switched from gigabit to a lower speed, TSO no longer could be enabled, even not via ifconfig(8). So this change moves the aforementioned WAR to em_update_link_status() like r308345 did, but only alters the hardware assist bits accordingly, leaving IFCAP_TSO4 flags alone. Still, this isn't the only problem r308345 had. Another one is that there just is no way to atomically flush TSO-using descriptors already queued at the point in time a link speed switch to below GbE occurs. Thus, such in-flight descriptors still may hang the MAC. Moreover, at least currently there also is no way of triggering a reconfiguration of vlan(4) when the state of IFCAP_VLAN_HWTSO support changes at runtime, causing vlan(4) to continue employing TSO. Last but not least, testing shows that - despite all the WARs for TSO-related silicon bugs in em(4) - at least 82579 still may hang at gigabit speed with IFCAP_TSO4 enabled. Therefore, this change further removes IFCAP_TSO4 and IFCAP_VLAN_HWTSO from interface capability enable bits as set by em(4). While at it, the use of CSUM_TCP is replaced with CSUM_IP_TSO as em(4) only implements support for IFCAP_TSO4 but not IFCAP_TSO6 (although in principle available with a subset of the supported MACs). At the bottom line, this change allows IFCAP_TSO4 and IFCAP_VLAN_HWTSO to be used again with em(4), but these hardware offloading capabilities now need to be explicitly enabled via ifconfig(8). Beware that it's only considered safe to do so (and also only may work) in environments where the link speed is not to be expected to change from GbE. Moreover, em(4) appears to still be missing some more TSO workarounds for at least some models, specifically the 82579 (I could not find an errata sheet and "specification update" respectively for these latter, though, and the generic ICH8 one doesn't list any TSO related bugs). - Let igb_tso_setup() handle EtherType protocols that are unsupported or for which support hasn't been compiled in gracefully instead of calling panic(9). - Make em_allocate_{legacy,msix}() and lem_allocate_irq() match their prototypes WRT static. This is a direct commit to stable/10 as corresponding code is no longer present in head. Approved by: re (gjb, kib)

MFC r322810 and r322830:

2017-09-06T15:33:23Z

Add new mlx5ib(4) driver to the kernel source tree which supports Remote DMA over Converged Ethernet, RoCE, for the ConnectX-4 series of PCI express network cards. There is currently no user-space support and this driver only supports kernel side non-routable RoCE V1. The krping kernel module can be used to test this driver. Full user-space support including RoCE V2 will be added as part of the ongoing upgrade to ibcore from Linux 4.9. Otherwise this driver is feature equivalent to mlx4ib(4). The mlx5ib(4) kernel module will only be built when WITH_OFED=YES is specified. Approved by: re (marius) Sponsored by: Mellanox Technologies

MFC: r308643, r312427, r312641, r322986

2017-08-31T23:59:46Z

- Update WOL support for newer em(4) devices. [1] - Add support for Kaby Lake generation i219 (4) and i219 (5) devices. - Enable WOL features also for the igb(4) class of devices. [1] - Don't set any WOL enabling hardware bits if WOL isn't requested according to the enabled interface capability bits. PR: 208343 [1] Submitted by: Kaho Tashikazu [1] Approved by: re (kib)

MFC r322852

2017-08-31T21:56:17Z

Fix qlnx_tso_check() so that every window of (ETH_TX_LSO_WINDOW_BDS_NUM - nbds_in_hdr) has atleast ETH_TX_LSO_WINDOW_MIN_LEN bytes Approved by:re(marius)

MFC 322771

2017-08-28T19:17:28Z

Upgrade FW to 5.4.66 sysctls to display stats, stats polled every 2 seconds Modify QLA_LOCK()/QLA_UNLOCK() to not sleep after acquiring mtx_lock Add support to turn OFF/ON error recovery following heartbeat failure for debug purposes. Set default max values to 32 Tx/Rx/SDS rings Approved by: re(gjb)

MFC r322408

2017-08-24T22:33:42Z

Performance enhancements to reduce CPU utililization for large number of TCP connections (order of tens of thousands), with predominantly Transmits. Submitted by: Vaishali.Kulkarni@cavium.com Approved by: re(marius)

MFC r322331

2017-08-24T18:01:17Z

Provide compile option to choose receive processing in either Ithread or Taskqueue Thread. Approved by: re(marius)

MFC 322299,322483,322485-322487

2017-08-21T05:25:30Z

322299 hyperv/hn: Implement transparent mode network VF. How network VF works with hn(4) on Hyper-V in transparent mode: - Each network VF has a cooresponding hn(4). - The network VF and the it's cooresponding hn(4) have the same hardware address. - Once the network VF is attached, the cooresponding hn(4) waits several seconds to make sure that the network VF attach routing completes, then: o Set the intersection of the network VF's if_capabilities and the cooresponding hn(4)'s if_capabilities to the cooresponding hn(4)'s if_capabilities. And adjust the cooresponding hn(4) if_capable and if_hwassist accordingly. (*) o Make sure that the cooresponding hn(4)'s TSO parameters meet the constraints posed by both the network VF and the cooresponding hn(4). (*) o The network VF's if_input is overridden. The overriding if_input changes the input packet's rcvif to the cooreponding hn(4). The network layers are tricked into thinking that all packets are neceived by the cooresponding hn(4). o If the cooresponding hn(4) was brought up, bring up the network VF. The transmission dispatched to the cooresponding hn(4) are redispatched to the network VF. o Bringing down the cooresponding hn(4) also brings down the network VF. o All IOCTLs issued to the cooresponding hn(4) are pass-through'ed to the network VF; the cooresponding hn(4) changes its internal state if necessary. o The media status of the cooresponding hn(4) solely relies on the network VF. o If there are multicast filters on the cooresponding hn(4), allmulti will be enabled on the network VF. (**) - Once the network VF is detached. Undo all damages did to the cooresponding hn(4) in the above item. NOTE: No operation should be issued directly to the network VF, if the network VF transparent mode is enabled. The network VF transparent mode can be enabled by setting tunable hw.hn.vf_transparent to 1. The network VF transparent mode is _not_ enabled by default, as of this commit. The benefit of the network VF transparent mode is that the network VF attachment and detachment are transparent to all network layers; e.g. live migration detaches and reattaches the network VF. The major drawbacks of the network VF transparent mode: - The netmap(4) support is lost, even if the VF supports it. - ALTQ does not work, since if_start method cannot be properly supported. (*) These decisions were made so that things will not be messed up too much during the transition period. (**) This does _not_ need to go through the fancy multicast filter management stuffs like what vlan(4) has, at least currently: - As of this write, multicast does not work in Azure. - As of this write, multicast packets go through the cooresponding hn(4). Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D11803 322483 hyperv/hn: Update VF's ibytes properly under transparent VF mode. While, I'm here add comment about why updating VF's imcast stat is not necessary. Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D11948 322485 hyperv/hn: Fix/enhance receiving path when VF is activated. - Update hn(4)'s stats properly for non-transparent mode VF. - Allow BPF tapping to hn(4) for non-transparent mode VF. - Don't setup mbuf hash, if 'options RSS' is set. In Azure, when VF is activated, TCP SYN and SYN|ACK go through hn(4) while the rest of segments and ACKs belonging to the same TCP 4-tuple go through the VF. So don't setup mbuf hash, if a VF is activated and 'options RSS' is not enabled. hn(4) and the VF may use neither the same RSS hash key nor the same RSS hash function, so the hash value for packets belonging to the same flow could be different! - Disable LRO. hn(4) will only receive broadcast packets, multicast packets, TCP SYN and SYN|ACK (in Azure), LRO is useless for these packet types. For non-transparent, we definitely _cannot_ enable LRO at all, since the LRO flush will use hn(4) as the receiving interface; i.e. hn_ifp->if_input(hn_ifp, m). While I'm here, remove unapplied comment and minor style change. Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D11978 322486 hyperv/hn: Minor cleanup Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D11979 322487 hyperv/hn: Re-set datapath after synthetic parts reattached. Do this even for non-transparent mode VF. Better safe than sorry. Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D11981 Approved by: re (delphij)

MFC: r266470, r273546, r276017, r277932, r279153, r279778, r279780, r278797,

2017-08-20T16:52:27Z

r278861, r280283, r280284, r280294, r280452, r280558, r280571, r281863, r282049, r282357, r282440, r282441, r282358, r282359, r283550, r283918, r290171, r290667, r290381, r290533, r290666, r292483, r295659, r297545, r298305, r298383, r298428, r306489, r306557, r307067, r307068, r307087, r307088, r307089, r307091, r307092, r307093, r307098, r307115, r307154, r307240, r307241, r315967, r316476 Unbreak BCM2835/RPI-B support by bringing it in line with stable/11 and head: - Optimise reading of pending interrupt registers. - Fix a bug where some DTS layouts could cause the premature ending of the search (i.e. without returning any result) and you would end up with a random MAC address. - Reduce the diff between head and arm_intrng with the bcm2835 interrupt controller. - Allow the retrieving of the reserved pins state. - Add support to the bcm2835 mailbox driver to work before interrupts are enabled. This will be needed to enable the power on devices early on in the boot process. - Add support for enabling the USB on the Raspberry Pi boards when it hasn't been done by U-Boot. This allows the USB to work when we load the kernel directly. - Call config_intrhook_disestablish on failure of the bcm2835 fb and fbd intr hooks. With this we can get through the boot even if these functions fail. - Add the structures needed to get/set the power state. These can be used when, for example, we boot without U-Boot and wish to enable USB, or to suspend an unneeded device. - Add a mask to match only the relative base address of BSC controllers. - Move the code to set the device power to the bcm2835 mailbox driver so it can be reused by other drivers. - Add the SOC_BCM2835 and SOC_BCM2836 options for the arm kernel and add the former to std.bcm2835. - Add a helper function to read clock frequencies from videocore and use this to get the default frequency of the sdhci device. - Add partial support for the Raspberry Pi 2. - Remove a debug #error from the bcm2835 sdhci driver. - Fetch the SDHCI frequency from videocore (our prefered source) and only if it fails, fetch the clock-frequency from DTB. If both methods fail, use the hardcoded default. - Pass the supplied buffer length instead of a fixed size. - Add the routines to query and setup the framebuffer state using the BCM2835_MBOX_CHAN_PROP channel. The old channel (BCM2835_MBOX_CHAN_FB) seems deprecated on recent firmware versions and is causing a freeze on RPi 2. - Fix DMA on RPi 2. BCM2836 has a different base address for peripherals. - Enable DMA for sdhci on RPi 2 (BCM2836). - Add a missing wakeup when releasing ownership of the SPI hardware. - Fix framebuffer compatibility with new RPi firmware. - Refactor bcm2835_cpufreq to use bcm2835_mbox_property API. - Fix the sc(4) framebuffer driver on RPi 2. - Fix the vt(4) framebuffer driver on RPi 2. - Remove unused mutex and softc variables. - Refactor mailbox property API to make it usable for /dev/vcio driver. - Replace semaphore-base locking with sleep/wait synchronization. - Fix infinite loop if response from VideoCore never received. - Set have_message in interrupt to handle "response before READ" case. - Serialize access to property channel when using bcm2835_mbox_property. - Force framebuffer virtual viewport to be the same as physical. - Use proper type of tag in bcm2835_mbox_fb_init. - bcm2835_cpufreq: Only attach driver if we correcly match on the machine compatible string. - Add dev.fb.X.resync sysctl to resync ARM framebuffer with VideoCore. - Do not use DMA channels used by GPU. - Define local-intc for BCM2836 platform (RPI2) and make BCM2835 intc a child of it. - Fix build for Pi kernels with syscons enabled. - Use VM_MEMATTR_WRITE_COMBINING memattr for mmap(2) on framebuffer. - Make intc driver compatible with upstream DTS. - Make Rapsberry Pi watchdog driver compatible with upstream DTS. - Make sure intc is attached before interrupt consumers. - Make framebuffer driver compatible with upstream DT. - Add one more heuristic to determine MAC address of the SMSC device. - Add compatibility strings from upstream DT. - Fix spelling mistake, BCM2835_PASWORD -> BCM2835_PASSWORD. Approved by: re (kib)