1. 13 5月, 2015 4 次提交
  2. 11 5月, 2015 4 次提交
  3. 30 4月, 2015 1 次提交
  4. 27 4月, 2015 1 次提交
  5. 09 4月, 2015 2 次提交
  6. 01 4月, 2015 4 次提交
  7. 30 3月, 2015 1 次提交
  8. 07 3月, 2015 1 次提交
  9. 25 2月, 2015 2 次提交
    • M
      bonding: Implement port churn-machine (AD standard 43.4.17). · 14c9551a
      Mahesh Bandewar 提交于
      The Churn Detection machines detect the situation where a port is operable,
      but the Actor and Partner have not attached the link to an Aggregator and
      brought the link into operation within a bound time period. Under normal
      operation of the LACP, agreement between Actor and Partner should be reached
      very rapidly. Continued failure to reach agreement can be symptomatic of
      device failure.
      
      Actor-churn-detection state-machine
      Reviewed-by: NNikolay Aleksandrov <nikolay@redhat.com>
      
      ===================================
      
      BEGIN=True + PortEnable=False
                 |
                 v
       +------------------------+   ActorPort.Sync=True  +------------------+
       |   ACTOR_CHURN_MONITOR  | ---------------------> |  NO_ACTOR_CHURN  |
       |========================|                        |==================|
       |    ActorChurn=False    |  ActorPort.Sync=False  | ActorChurn=False |
       | ActorChurn.Timer=Start | <--------------------- |                  |
       +------------------------+                        +------------------+
                 |                                                ^
                 |                                                |
        ActorChurn.Timer=Expired                                  |
                 |                                       ActorPort.Sync=True
                 |                                                |
                 |                +-----------------+             |
                 |                |   ACTOR_CHURN   |             |
                 |                |=================|             |
                 +--------------> | ActorChurn=True | ------------+
                                  |                 |
                                  +-----------------+
      
      Similar for the Partner-churn-detection.
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14c9551a
    • M
      bonding: Verify RX LACPDU has proper dest mac-addr · bb54e589
      Mahesh Bandewar 提交于
      The 802.1AX standard states:
      "The DA in LACPDUs is the Slow_Protocols_Multicast address."
      
      This patch enforces that and drops LACPDUs with destination MAC
      addresses other than Slow_Protocols_Multicast address
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb54e589
  10. 21 2月, 2015 1 次提交
  11. 10 2月, 2015 1 次提交
  12. 05 2月, 2015 2 次提交
  13. 02 2月, 2015 1 次提交
  14. 28 1月, 2015 5 次提交
  15. 26 1月, 2015 1 次提交
    • E
      bonding: handle more gso types · 24f87d4c
      Eric Dumazet 提交于
      In commit 5a7baa78 ("bonding: Advertize vxlan offload features when
      supported"), Or Gerlitz added support conditional vxlan offload.
      
      In this patch I also add support for all kind of tunnels,
      but we allow a bonding device to not require segmentation,
      as it is always better to make this segmentation at the very last stage,
      if a particular slave device requires it.
      
      Tested:
      
       Setup a GRE tunnel,
       on a physical NIC not having tx-gre-segmentation.
       Results on bnx2x are even better, as we no longer have to segment
       in software.
      
      ethtool -K bond0 tx-gre-segmentation off
      
      super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
      7538.32
      
      ethtool -K bond0 tx-gre-segmentation on
      
      super_netperf 50 --google-pacing-rate 30000000 -H 10.7.8.152 -l 15
      10200.5
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24f87d4c
  16. 13 1月, 2015 1 次提交
    • J
      bonding: cleanup bond_opts array · 7bfa0145
      Jonathan Toppins 提交于
      Remove the empty array element initializer and size the array with
      BOND_OPT_LAST so the compiler will complain if more elements are in
      there than should be.
      
      An interesting unwanted side effect of this initializer is that if one
      inserts new options into the middle of the array then this initializer
      will zero out the option that equals BOND_OPT_TLB_DYNAMIC_LB+1.
      
      Example:
      Extend the OPTS enum:
      enum {
         ...
         BOND_OPT_TLB_DYNAMIC_LB,
         BOND_OPT_LACP_NEW1,
         BOND_OPT_LAST
      };
      
      Now insert into bond_opts array:
      static const struct bond_option bond_opts[] = {
            ...
            [BOND_OPT_LACP_RATE] = { .... unchanged stuff .... },
            [BOND_OPT_LACP_NEW1] = { ... new stuff ... },
            ...
            [BOND_OPT_TLB_DYNAMIC_LB] = { .... unchanged stuff ....},
            { } // MARK A
      };
      
      Since BOND_OPT_LACP_NEW1 = BOND_OPT_TLB_DYNAMIC_LB+1, the last
      initializer (MARK A) will overwrite the contents of BOND_OPT_LACP_NEW1
      and can be easily viewed with the crash utility.
      Signed-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
      Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
      Cc: Nikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
      Acked-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7bfa0145
  17. 27 12月, 2014 1 次提交
  18. 30 11月, 2014 1 次提交
  19. 22 11月, 2014 2 次提交
  20. 20 11月, 2014 3 次提交
    • J
      bonding: Introduce 4 AD link speed to fix agg_bandwidth · 424c3232
      Jianhua Xie 提交于
      This patch adds [2.5|20|40|56] Gbps enum definition, and fixes
      aggregated bandwidth calculation based on above slave links.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NJianhua Xie <jianhua.xie@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      424c3232
    • J
      bonding: change AD_LINK_SPEED_BITMASK to enum to suport more speed · cb8dda90
      Jianhua Xie 提交于
      Port Key was determined as 16 bits according to the link speed,
      duplex and user key (which is yet not supported).  In the old
      speed field, 5 bits are for speed [1|10|100|1000|10000]Mbps as
      below:
      --------------------------------------------------------------
      Port key :| User key        | Speed         |       Duplex|
      --------------------------------------------------------------
          16                  6               1               0
      This patch keeps the old layout, but changes AD_LINK_SPEED_BITMASK
      from bit type to an enum type.  In this way, the speed field can
      expand speed type from 5 to 32.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NJianhua Xie <jianhua.xie@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb8dda90
    • N
      bonding: fix curr_active_slave/carrier with loadbalance arp monitoring · b8e4500f
      Nikolay Aleksandrov 提交于
      Since commit 6fde8f03 ("bonding: fix locking in
      bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
      stale curr_active_slave when using arp monitoring in loadbalance modes. The
      reason is that in bond_loadbalance_arp_mon() we can't have
      do_failover == true but slave_state_changed == false, whenever do_failover
      is true then slave_state_changed is also true. Then the following piece
      from bond_loadbalance_arp_mon():
                      if (slave_state_changed) {
                              bond_slave_state_change(bond);
                              if (BOND_MODE(bond) == BOND_MODE_XOR)
                                      bond_update_slave_arr(bond, NULL);
                      } else if (do_failover) {
                              block_netpoll_tx();
                              bond_select_active_slave(bond);
                              unblock_netpoll_tx();
                      }
      
      will execute only the first branch, always and regardless of do_failover.
      Since these two events aren't related in such way, we need to decouple and
      consider them separately.
      
      For example this issue could lead to the following result:
      Bonding Mode: load balancing (round-robin)
      *MII Status: down*
      MII Polling Interval (ms): 0
      Up Delay (ms): 0
      Down Delay (ms): 0
      ARP Polling Interval (ms): 100
      ARP IP target/s (n.n.n.n form): 192.168.9.2
      
      Slave Interface: ens12
      *MII Status: up*
      Speed: 10000 Mbps
      Duplex: full
      Link Failure Count: 2
      Permanent HW addr: 00:0f:53:01:42:2c
      Slave queue ID: 0
      
      Slave Interface: eth1
      *MII Status: up*
      Speed: Unknown
      Duplex: Unknown
      Link Failure Count: 70
      Permanent HW addr: 52:54:00:2f:0f:8e
      Slave queue ID: 0
      
      Since some interfaces are up, then the status of the bond should also be
      up, but it will never change unless something invokes bond_set_carrier()
      (i.e. enslave, bond_select_active_slave etc). Now, if I force the
      calling of bond_select_active_slave via for example changing
      primary_reselect (it can change in any mode), then the MII status goes to
      "up" because it calls bond_select_active_slave() which should've been done
      from bond_loadbalance_arp_mon() itself.
      
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Ding Tianhong <dingtianhong@huawei.com>
      
      Fixes: 6fde8f03 ("bonding: fix locking in bond_loadbalance_arp_mon()")
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NVeaceslav Falico <vfalico@gmail.com>
      Acked-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
      Acked-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8e4500f
  21. 14 11月, 2014 1 次提交
    • M
      net: generic dev_disable_lro() stacked device handling · fbe168ba
      Michal Kubeček 提交于
      Large receive offloading is known to cause problems if received packets
      are passed to other host. Therefore the kernel disables it by calling
      dev_disable_lro() whenever a network device is enslaved in a bridge or
      forwarding is enabled for it (or globally). For virtual devices we need
      to disable LRO on the underlying physical device (which is actually
      receiving the packets).
      
      Current dev_disable_lro() code handles this  propagation for a vlan
      (including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
      It doesn't handle other stacked devices and their combinations, in
      particular propagation from a bond to its slaves which often causes
      problems in virtualization setups.
      
      As we now have generic data structures describing the upper-lower device
      relationship, dev_disable_lro() can be generalized to disable LRO also
      for all lower devices (if any) once it is disabled for the device
      itself.
      
      For bonding and teaming devices, it is necessary to disable LRO not only
      on current slaves at the moment when dev_disable_lro() is called but
      also on any slave (port) added later.
      
      v2: use lower device links for all devices (including vlan and macvlan)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NVeaceslav Falico <vfalico@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbe168ba