- 17 Feb, 2020 40 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2020-02-15 This series contains updates to ice driver only. Brett adds support for "Queue in Queue" (QinQ) support, by supporting S-tag & C-tag VLAN traffic by disabling pruning when there are no 0x8100 VLAN interfaces currently on top of the PF. Also refactored the port VLAN configuration to re-use the common code for enabling and disabling a port VLAN in single function. Added a helper function to determine if the VF link is up. Fixed how the port VLAN configures the priority bits for a VF interface. Fixed the port VLAN to only see its own broadcast and multicast traffic. Added support to enable and disable all receive queues, by refactoring adding a new function to do the necessary steps to enable/disable a queue with the necessary read flush. Fixed how we set the mapping mode for transmit and receive queues. Added support for VF queues to handle LAN overflow events. Fixed and refactored how receive queues get disabled for VFs, which was being handled one queue at at time, so improve it to handle when the VF is requesting more than one queue to be disabled. Fixed how the virtchnl_queue_select bitmap is validated. Finally a patch not authored by Brett, Bruce cleans up "fallthrough" comments which are unnecessary. Also replaces the "fallthough" comments with the GCC reserved word fallthrough, along with other GCC compiler fixes. Add missing function header comment regarding a function argument that was missing. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Finn Thain says: ==================== Improvements for SONIC ethernet drivers Now that the necessary sonic driver fixes have been merged, and the merge window has closed again, I'm sending the remainder of my sonic driver patch queue. A couple of these patches will have to be applied in sequence to avoid 'git am' rejects. The others are independent and could have been submitted individually. Please let me know if I should do that. The complete sonic driver patch queue was tested on National Semiconductor hardware (macsonic), qemu-system-m68k (macsonic) and qemu-system-mips64el (jazzsonic). ==================== Signed-off-by: -
Finn Thain authored
On m68k, local irqs remain enabled while interrupt handlers execute. Therefore the macsonic driver has had to disable interrupts to avoid re-entering sonic_interrupt(). As of commit 865ad2f2 ("net/sonic: Add mutual exclusion for accessing shared state"), sonic_interrupt() became re-entrant, and its wrapper became redundant. Tested-by:
Stan Johnson <userm57@yahoo.com> Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
-
Finn Thain authored
Give the transmit command as soon as the transmit descriptor is ready. Tested-by:
-
Finn Thain authored
The explicit memory barriers are redundant now that proper locking and MMIO accessors have been employed. Tested-by:
-
Finn Thain authored
The transmit queue must be running already otherwise sonic_send_packet() would not have been called. If the queue was stopped by the interrupt handler, the interrupt handler will restart it again. Tested-by:
-
Finn Thain authored
The eol_tx variable is the one that matters to the tx algorithm because packets are always placed at the end of the list. The next_tx variable just confuses things so remove it. Tested-by:
-
Finn Thain authored
No functional change. Tested-by:
-
Finn Thain authored
The comment is meaningless since mark_bh() was removed a long time ago. Tested-by:
-
David S. Miller authored
Sergei Shtylyov says: ==================== sh_eth: get rid of the dedicated regiseter mapping for RZ/A1 (R7S72100) Here's a set of 5 patches against DaveM's 'net-next.git' repo. I changed my mind about the RZ/A1 SoC needing its own register map -- now that we don't depend on the register map array in order to determine whether a given register exists any more, we can add a new flag to determine if the GECMR exists (this register is present only on true GEther chips, not RZ/A1). We also need to add the sh_eth_cpu_data::* flag checks where they were missing so far: in the ethtool API for the register dump. ==================== Signed-off-by: -
Sergei Shtylyov authored
The register maps for the Gigabit controllers and the Ether one used on RZ/A1 (AKA R7S72100) are identical except for GECMR which is only present on the true GEther controllers. We no longer use the register map arrays to determine if a given register exists, and have added the GECMR flag to the 'struct sh_eth_cpu_data' in the previous patch, so we're ready to drop the R7S72100 specific register map -- this saves 216 bytes of object code (ARM gcc 4.8.5). Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Tested-by:
Chris Brandt <chris.brandt@renesas.com> Signed-off-by:
-
Sergei Shtylyov authored
Not all Ether controllers having the Gigabit register layout have GECMR -- RZ/A1 (AKA R7S72100) actually has the same layout but no Gigabit speed support and hence no GECMR. In the past, the new register map table was added for this SoC, now I think we should have used the existing Gigabit table with the differences (such as GECMR) covered by the mere flags in the 'struct sh_eth_cpu_data'. Add such flag for GECMR -- and then we can get rid of the R7S72100 specific layout in the next patch... Signed-off-by:
-
Sergei Shtylyov authored
When adding the sh_eth_cpu_data::no_xdfar flag I forgot to add the flag check to __sh_eth_get_regs(), causing the non-existing RDFAR/TDFAR to be considered for dumping on the R-Car gen1/2 SoCs (the register offset check has the final say here)... Fixes: 4c1d4585 ("sh_eth: add sh_eth_cpu_data::cexcr flag") Signed-off-by:
-
Sergei Shtylyov authored
When adding the sh_eth_cpu_data::cexcr flag I forgot to add the flag check to __sh_eth_get_regs(), causing the non-existing RX packet counter registers to be considered for dumping on the R7S72100 SoC (the register offset sanity check has the final say here)... Fixes: 4c1d4585 ("sh_eth: add sh_eth_cpu_data::cexcr flag") Signed-off-by:
-
Sergei Shtylyov authored
When adding the sh_eth_cpu_data::no_tx_cntrs flag I forgot to add the flag check to __sh_eth_get_regs(), causing the non-existing TX counter registers to be considered for dumping on the R7S72100 SoC (the register offset sanity check has the final say here)... Fixes: ce9134df ("sh_eth: add sh_eth_cpu_data::no_tx_cntrs flag") Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== Pause updates for phylib and phylink Currently, phylib resolves the speed and duplex settings, which MAC drivers use directly. phylib also extracts the "Pause" and "AsymPause" bits from the link partner's advertisement, and stores them in struct phy_device's pause and asym_pause members with no further processing. It is left up to each MAC driver to implement decoding for this information. phylink converted drivers are able to take advantage of code therein which resolves the pause advertisements for the MAC driver, but this does nothing for unconverted drivers. It also does not allow us to make use of hardware-resolved pause states offered by several PHYs. This series aims to address this by: 1. Providing a generic implementation, linkmode_resolve_pause(), that takes the ethtool linkmode arrays for the link partner and local advertisements, decoding the result to whether pause frames should be allowed to be transmitted or received and acted upon. I call this the pause enablement state. 2. Providing a phylib implementation, phy_get_pause(), which allows MAC drivers to request the pause enablement state from phylib. 3. Providing a generic linkmode_set_pause() for setting the pause advertisement according to the ethtool tx/rx flags - note that this design has some shortcomings, see the comments in the kerneldoc for this function. 4. Remove the ability in phylink to set the pause states for fixed links, which brings them into line with how we deal with the speed and duplex parameters; we can reintroduce this later if anyone requires it. This could be a userspace-visible change. 5. Split application of manual pause enablement state from phylink's resolution of the same to allow use of phylib's new phy_get_pause() interface by phylink, and make that switch. 6. Resolve the fixed-link pause enablement state using the generic linkmode_resolve_pause() helper introduced earlier. This, in connection with the previous commits, allows us to kill the MLO_PAUSE_SYM and MLO_PAUSE_ASYM flags. 7. make phylink's ethtool pause setting implementation update the pause advertisement in the same way that phylib does, with the same caveats that are present there (as mentioned above w.r.t linkmode_set_pause()). 8. create a more accurate initial configuration for MACs, used when phy_start() is called or a SFP is detected. In particular, this ensures that the pause bits seen by MAC drivers in state->pause are accurate for SGMII. 9. finally, update the kerneldoc descriptions for mac_config() for the above changes. This series has been build-tested against net-next; the boot tested patches are in my "phy" branch against v5.5 plus the queued phylink changes that were merged for 5.6. The next series will introduce the ability for phylib drivers to provide hardware resolved pause enablement state. These patches can be found in my "phy" branch. ==================== Signed-off-by: -
Russell King authored
Clarify the expected flow control settings operation in the phylink documentation for each negotiation mode. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King authored
Improve the initial MAC configuration so we get a configuration which more represents the final operating mode, in particular with respect to the flow control settings. We do this by: 1) more fully initialising our phy state, so we can use this as the initial state for PHY based connections. 2) reading the fixed link state. 3) ensuring that in-band mode has sane pause settings for SGMII vs 802.3z negotiation modes. In all three cases, we ensure that state->link is false, just in case any MAC drivers have other ideas by mis-using this member, and we also take account of manual pause mode configuration at this point. This avoids MLO_PAUSE_AN being seen in mac_config() when operating in PHY, fixed mode or inband SGMII mode, thereby giving cleaner semantics to the pause flags. As a result of this, the pause flags now indicate in a mode-independent way what is required from a mac_config() implementation. Signed-off-by:
-
Russell King authored
When ethtool -A is used to change the pause modes, the pause advertisement is not being changed, but the documentation in uapi/linux/ethtool.h says we should be. Add that capability to phylink. Signed-off-by:
-
Russell King authored
Resolve the fixed link flow control using the recently introduced linkmode_resolve_pause() helper, which we use in phylink_get_fixed_state() only when operating in full duplex mode. Signed-off-by:
-
Russell King authored
Use the new phy_get_pause() helper to get the resolved pause modes for a PHY rather than resolving the pause modes ourselves. We temporarily retain our pause mode resolution for causes where there is no PHY attached, e.g. for fixed-link modes. Signed-off-by:
-
Russell King authored
Split the application of manually controlled flow control modes from phylink_resolve_flow(), so that we can use alternative providers of flow control resolution. We also want to clear the MLO_PAUSE_AN flag when autoneg is disabled, since flow control can't be negotiated in this circumstance. Signed-off-by:
-
Russell King authored
Remove the ability for ethtool -A to change the pause settings for fixed links; if this is really required, we can reinstate it later. Andrew Lunn agrees: "So I think it is safe to not implement ethtool -A, at least until somebody has a real use case for it." Lets avoid making things too complex for use cases that aren't being used. Signed-off-by:
-
Russell King authored
Add a linkmode helper to set the flow control advertisement in an ethtool linkmode mask according to the tx/rx capabilities. This implementation is moved from phylib, and documented with an analysis of its shortcomings. Signed-off-by:
-
Russell King authored
Add a couple of helpers to resolve negotiated flow control. Two helpers are provided: - linkmode_resolve_pause() which takes the link partner and local advertisements, and decodes whether we should enable TX or RX pause at the MAC. This is useful outside of phylib, e.g. in phylink. - phy_get_pause(), which returns the TX/RX enablement status for the current negotiation results of the PHY. This allows us to centralise the flow control resolution, rather than spreading it around. Signed-off-by:
-
Russell King authored
linkmode_test_bit() does not modify the address; test_bit() is also declared const volatile for the same reason. There's no need for linkmode_test_bit() to be any different, and allows implementation of helpers that take a const linkmode pointer. Reviewed-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: series with further smaller improvements Nothing too exciting. This series includes further smaller improvements. ==================== Signed-off-by: -
Heiner Kallweit authored
Register RxMissed exists on few early chip versions only, however all chip versions have the number of missed RX packets in the hardware counters. Therefore remove using RxMissed and get the number of missed RX packets from the hardware stats. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Merge enabling and disabling jumbo packets to one function to make the code a little simpler. Signed-off-by:
-
Heiner Kallweit authored
Currently code snippet (RTL_R32(tp, TxConfig) >> 20) & 0xfcf is used in few places to extract the chip XID. Change the code to do the XID extraction only once. Signed-off-by:
-
Heiner Kallweit authored
In few places we do a PCI commit by reading an arbitrary chip register. It's not always obvious that the read is meant to be a PCI commit, therefore add a helper for it. Signed-off-by:
-
Heiner Kallweit authored
Setting dev->features a few lines later allows to simplify the code. Signed-off-by:
-
Heiner Kallweit authored
This is done for all RTL8169 chip versions in rtl8169_init_phy already. Therefore we can remove it here. Signed-off-by:
-
Heiner Kallweit authored
rtl_link_chg_patch() can be called from rtl_open() to rtl8169_close() only. And in rtl8169_close() phy_stop() ensures that this function isn't called afterwards. So we don't need this check. Signed-off-by:
-
Matteo Croce authored
New action to decrement TTL instead of setting it to a fixed value. This action will decrement the TTL and, in case of expired TTL, drop it or execute an action passed via a nested attribute. The default TTL expired action is to drop the packet. Supports both IPv4 and IPv6 via the ttl and hop_limit fields, respectively. Tested with a corresponding change in the userspace: # ovs-dpctl dump-flows in_port(2),eth(),eth_type(0x0800), packets:0, bytes:0, used:never, actions:dec_ttl{ttl<=1 action:(drop)},1 in_port(1),eth(),eth_type(0x0800), packets:0, bytes:0, used:never, actions:dec_ttl{ttl<=1 action:(drop)},2 in_port(1),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, actions:2 in_port(2),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, actions:1 # ping -c1 192.168.0.2 -t 42 IP (tos 0x0, ttl 41, id 61647, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > 192.168.0.2: ICMP echo request, id 386, seq 1, length 64 # ping -c1 192.168.0.2 -t 120 IP (tos 0x0, ttl 119, id 62070, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > 192.168.0.2: ICMP echo request, id 388, seq 1, length 64 # ping -c1 192.168.0.2 -t 1 # Co-developed-by:Bindiya Kurle <bindiyakurle@gmail.com> Signed-off-by:
Matteo Croce <mcroce@redhat.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
Florian Fainelli authored
Either port 5 or port 8 can be used on a 7278 device, make sure that port 5 also gets configured properly for 2Gb/sec in that case. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Arjun Roy authored
This patchset is intended to reduce the number of extra system calls imposed by TCP receive zerocopy. For ping-pong RPC style workloads, this patchset has demonstrated a system call reduction of about 30% when coupled with userspace changes. For applications using epoll, returning sk_err along with the result of tcp receive zerocopy could remove the need to call recvmsg()=-EAGAIN after a spurious wakeup. Consider a multi-threaded application using epoll. A thread may awaken with EPOLLIN but another thread may already be reading. The spuriously-awoken thread does not necessarily know that another thread 'won'; rather, it may be possible that it was woken up due to the presence of an error if there is no data. A zerocopy read receiving 0 bytes thus would need to be followed up by recvmsg to be sure. Instead, we return sk_err directly with zerocopy, so the application can avoid this extra system call. Signed-off-by:
Arjun Roy <arjunroy@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Arjun Roy authored
This patchset is intended to reduce the number of extra system calls imposed by TCP receive zerocopy. For ping-pong RPC style workloads, this patchset has demonstrated a system call reduction of about 30% when coupled with userspace changes. For applications using edge-triggered epoll, returning inq along with the result of tcp receive zerocopy could remove the need to call recvmsg()=-EAGAIN after a successful zerocopy. Generally speaking, since normally we would need to perform a recvmsg() call for every successful small RPC read via TCP receive zerocopy, returning inq can reduce the number of system calls performed by approximately half. Signed-off-by:
-
David S. Miller authored
Sebastien Boeuf says: ==================== Enhance virtio-vsock connection semantics This series improves the semantics behind the way virtio-vsock server accepts connections coming from the client. Whenever the server receives a connection request from the client, if it is bound to the socket but not yet listening, it will answer with a RST packet. The point is to ensure each request from the client is quickly processed so that the client can decide about the strategy of retrying or not. The series includes along with the improvement patch a new test to ensure the behavior is consistent across all hypervisors drivers. ==================== Signed-off-by: -
Sebastien Boeuf authored
Whenever the server side of vsock is binding to the socket, but not listening yet, we expect the behavior from the client to be identical to what happens when the server is not even started. This new test runs the server side so that it binds to the socket without ever listening to it. The client side will try to connect and should receive an ECONNRESET error. This new test provides a way to validate the previously introduced patch for making sure the server side will always answer with a RST packet in case the client requested a new connection. Signed-off-by:
Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by:
-
