1. 04 8月, 2017 3 次提交
  2. 25 7月, 2017 2 次提交
  3. 30 6月, 2017 2 次提交
  4. 22 6月, 2017 3 次提交
  5. 21 6月, 2017 1 次提交
  6. 20 6月, 2017 1 次提交
  7. 17 6月, 2017 1 次提交
    • N
      ibmvnic: driver initialization for kdump/kexec · 6a2fb0e9
      Nathan Fontenot 提交于
      When booting into the kdump/kexec kernel, pHyp and vios
      are not prepared for the initialization crq request and
      a failover transport event is generated. This is not
      handled correctly.
      
      At this point in initialization the driver is still in
      the 'probing' state and cannot handle a full reset of the
      driver as is normally done for a failover transport event.
      
      To correct this we catch driver resets while still in the
      'probing' state and return EAGAIN. This results in the
      driver tearing down the main crq and calling ibmvnic_init()
      again.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a2fb0e9
  8. 16 6月, 2017 5 次提交
  9. 14 6月, 2017 2 次提交
    • N
      ibmvnic: Remove netdev notify for failover resets · 61d3e1d9
      Nathan Fontenot 提交于
      When handling a driver reset due to a failover of the backing
      server on the vios, doing the netdev_notify_peers() can cause
      network traffic to stall or halt. Remove the netdev notify call
      for failover resets.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61d3e1d9
    • T
      ibmvnic: Client-initiated failover · 40c9db8a
      Thomas Falcon 提交于
      The IBM vNIC protocol provides support for the user to initiate
      a failover from the client LPAR in case the current backing infrastructure
      is deemed inadequate or in an error state.
      
      Support for two H_VIOCTL sub-commands for vNIC devices are required
      to implement this function. These commands are H_GET_SESSION_TOKEN
      and H_SESSION_ERR_DETECTED.
      
      "[H_GET_SESSION_TOKEN] is used to obtain a session token from a VNIC client
      adapter.  This token is opaque to the caller and is intended to be used in
      tandem with the SESSION_ERROR_DETECTED vioctl subfunction."
      
      "[H_SESSION_ERR_DETECTED] is used to report that the currently active
      backing device for a VNIC client adapter is behaving poorly, and that
      the hypervisor should attempt to fail over to a different backing device,
      if one is available."
      
      To provide tools access to this functionality the vNIC driver creates a
      sysfs file that, when written to, will send a request to pHyp to failover
      to a different backing device.
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Reviewed-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40c9db8a
  10. 12 6月, 2017 1 次提交
  11. 09 6月, 2017 1 次提交
  12. 08 6月, 2017 3 次提交
    • C
      net: emac: fix and unify emac_mdio functions · 9065bc38
      Christian Lamparter 提交于
      emac_mdio_read_link() was not copying the requested phy settings
      back into the emac driver's own phy api. This has caused a link
      speed mismatch issue for the AR8035 as the emac driver kept
      trying to connect with 10/100MBps on a 1GBit/s link.
      
      This patch also unifies shared code between emac_setup_aneg()
      and emac_mdio_setup_forced(). And furthermore it removes
      a chunk of emac_mdio_init_phy(), that was copying the same
      data into itself.
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9065bc38
    • C
      net: emac: fix reset timeout with AR8035 phy · 19d90ece
      Christian Lamparter 提交于
      This patch fixes a problem where the AR8035 PHY can't be
      detected on an Cisco Meraki MR24, if the ethernet cable is
      not connected on boot.
      
      Russell Senior provided steps to reproduce the issue:
      |Disconnect ethernet cable, apply power, wait until device has booted,
      |plug in ethernet, check for interfaces, no eth0 is listed.
      |
      |This appears to be a problem during probing of the AR8035 Phy chip.
      |When ethernet has no link, the phy detection fails, and eth0 is not
      |created. Plugging ethernet later has no effect, because there is no
      |interface as far as the kernel is concerned. The relevant part of
      |the boot log looks like this:
      |this is the failing case:
      |
      |[    0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
      |[    0.882532] /plb/opb/ethernet@ef600c00: reset timeout
      |[    0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
      |and the succeeding case:
      |
      |[    0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
      |[    0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
      |[    0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)
      
      Based on the comment and the commit message of
      commit 23fbb5a8 ("emac: Fix EMAC soft reset on 460EX/GT").
      This is because the AR8035 PHY doesn't provide the TX Clock,
      if the ethernet cable is not attached. This causes the reset
      to timeout and the PHY detection code in emac_init_phy() is
      unable to detect the AR8035 PHY. As a result, the emac driver
      bails out early and the user left with no ethernet.
      
      In order to stay compatible with existing configurations, the driver
      tries the current reset approach at first. Only if the first attempt
      timed out, it does perform one more retry with the clock temporarily
      switched to the internal source for just the duration of the reset.
      
      LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687>
      
      Cc: Chris Blake <chrisrblake93@gmail.com>
      Reported-by: NRussell Senior <russell@personaltelco.net>
      Fixes: 23fbb5a8 ("emac: Fix EMAC soft reset on 460EX/GT")
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19d90ece
    • J
      ibmvnic: Return failure on attempted mtu change · 3a807b75
      John Allen 提交于
      Changing the mtu is currently not supported in the ibmvnic driver.
      
      Implement .ndo_change_mtu in the driver so that attempting to use ifconfig
      to change the mtu will fail and present the user with an error message.
      Signed-off-by: NJohn Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a807b75
  13. 03 6月, 2017 1 次提交
  14. 27 5月, 2017 11 次提交
  15. 22 5月, 2017 1 次提交
    • S
      ibmveth: Support to enable LSO/CSO for Trunk VEA. · 66aa0678
      Sivakumar Krishnasamy 提交于
      Current largesend and checksum offload feature in ibmveth driver,
       - Source VM sends the TCP packets with ip_summed field set as
         CHECKSUM_PARTIAL and TCP pseudo header checksum is placed in
         checksum field
       - CHECKSUM_PARTIAL flag in SKB will enable ibmveth driver to mark
         "no checksum" and "checksum good" bits in transmit buffer descriptor
         before the packet is delivered to pseries PowerVM Hypervisor
       - If ibmveth has largesend capability enabled, transmit buffer descriptors
         are market accordingly before packet is delivered to Hypervisor
         (along with mss value for packets with length > MSS)
       - Destination VM's ibmveth driver receives the packet with "checksum good"
         bit set and so, SKB's ip_summed field is set with CHECKSUM_UNNECESSARY
       - If "largesend" bit was on, mss value is copied from receive descriptor
         into SKB's gso_size and other flags are appropriately set for
         packets > MSS size
       - The packet is now successfully delivered up the stack in destination VM
      
      The offloads described above works fine for TCP communication among VMs in
      the same pseries server ( VM A <=> PowerVM Hypervisor <=> VM B )
      
      We are now enabling support for OVS in pseries PowerVM environment. One of
      our requirements is to have ibmveth driver configured in "Trunk" mode, when
      they are used with OVS. This is because, PowerVM Hypervisor will no more
      bridge the packets between VMs, instead the packets are delivered to
      IO Server which hosts OVS to bridge them between VMs or to external
      networks (flow shown below),
        VM A <=> PowerVM Hypervisor <=> IO Server(OVS) <=> PowerVM Hypervisor
                                                                         <=> VM B
      In "IO server" the packet is received by inbound Trunk ibmveth and then
      delivered to OVS, which is then bridged to outbound Trunk ibmveth (shown
      below),
              Inbound Trunk ibmveth <=> OVS <=> Outbound Trunk ibmveth
      
      In this model, we hit the following issues which impacted the VM
      communication performance,
      
       - Issue 1: ibmveth doesn't support largesend and checksum offload features
         when configured as "Trunk". Driver has explicit checks to prevent
         enabling these offloads.
      
       - Issue 2: SYN packet drops seen at destination VM. When the packet
         originates, it has CHECKSUM_PARTIAL flag set and as it gets delivered to
         IO server's inbound Trunk ibmveth, on validating "checksum good" bits
         in ibmveth receive routine, SKB's ip_summed field is set with
         CHECKSUM_UNNECESSARY flag. This packet is then bridged by OVS (or Linux
         Bridge) and delivered to outbound Trunk ibmveth. At this point the
         outbound ibmveth transmit routine will not set "no checksum" and
         "checksum good" bits in transmit buffer descriptor, as it does so only
         when the ip_summed field is CHECKSUM_PARTIAL. When this packet gets
         delivered to destination VM, TCP layer receives the packet with checksum
         value of 0 and with no checksum related flags in ip_summed field. This
         leads to packet drops. So, TCP connections never goes through fine.
      
       - Issue 3: First packet of a TCP connection will be dropped, if there is
         no OVS flow cached in datapath. OVS while trying to identify the flow,
         computes the checksum. The computed checksum will be invalid at the
         receiving end, as ibmveth transmit routine zeroes out the pseudo
         checksum value in the packet. This leads to packet drop.
      
       - Issue 4: ibmveth driver doesn't have support for SKB's with frag_list.
         When Physical NIC has GRO enabled and when OVS bridges these packets,
         OVS vport send code will end up calling dev_queue_xmit, which in turn
         calls validate_xmit_skb.
         In validate_xmit_skb routine, the larger packets will get segmented into
         MSS sized segments, if SKB has a frag_list and if the driver to which
         they are delivered to doesn't support NETIF_F_FRAGLIST feature.
      
      This patch addresses the above four issues, thereby enabling end to end
      largesend and checksum offload support for better performance.
      
       - Fix for Issue 1 : Remove checks which prevent enabling TCP largesend and
         checksum offloads.
       - Fix for Issue 2 : When ibmveth receives a packet with "checksum good"
         bit set and if its configured in Trunk mode, set appropriate SKB fields
         using skb_partial_csum_set (ip_summed field is set with
         CHECKSUM_PARTIAL)
       - Fix for Issue 3: Recompute the pseudo header checksum before sending the
         SKB up the stack.
       - Fix for Issue 4: Linearize the SKBs with frag_list. Though we end up
         allocating buffers and copying data, this fix gives
         upto 4X throughput increase.
      
      Note: All these fixes need to be dropped together as fixing just one of
      them will lead to other issues immediately (especially for Issues 1,2 & 3).
      Signed-off-by: NSivakumar Krishnasamy <ksiva@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66aa0678
  16. 19 5月, 2017 1 次提交
  17. 03 5月, 2017 1 次提交