1. 20 10月, 2013 2 次提交
  2. 04 10月, 2013 1 次提交
    • N
      bonding: modify the old and add new xmit hash policies · 32819dc1
      Nikolay Aleksandrov 提交于
      This patch adds two new hash policy modes which use skb_flow_dissect:
      3 - Encapsulated layer 2+3
      4 - Encapsulated layer 3+4
      There should be a good improvement for tunnel users in those modes.
      It also changes the old hash functions to:
      hash ^= (__force u32)flow.dst ^ (__force u32)flow.src;
      hash ^= (hash >> 16);
      hash ^= (hash >> 8);
      
      Where hash will be initialized either to L2 hash, that is
      SRCMAC[5] XOR DSTMAC[5], or to flow->ports which should be extracted
      from the upper layer. Flow's dst and src are also extracted based on the
      xmit policy either directly from the buffer or by using skb_flow_dissect,
      but in both cases if the protocol is IPv6 then dst and src are obtained by
      ipv6_addr_hash() on the real addresses. In case of a non-dissectable
      packet, the algorithms fall back to L2 hashing.
      The bond_set_mode_ops() function is now obsolete and thus deleted
      because it was used only to set the proper hash policy. Also we trim a
      pointer from struct bonding because we no longer need to keep the hash
      function, now there's only a single hash function - bond_xmit_hash that
      works based on bond->params.xmit_policy.
      
      The hash function and skb_flow_dissect were suggested by Eric Dumazet.
      The layer names were suggested by Andy Gospodarek, because I suck at
      semantics.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32819dc1
  3. 01 10月, 2013 2 次提交
    • V
      bonding: RCUify bond_set_rx_mode() · b3241870
      Veaceslav Falico 提交于
      Currently we rely on rtnl locking in bond_set_rx_mode(), however it's not
      always the case:
      
      RTNL: assertion failed at drivers/net/bonding/bond_main.c (3391)
      ...
       [<ffffffff81651ca5>] dump_stack+0x54/0x74
       [<ffffffffa029e717>] bond_set_rx_mode+0xc7/0xd0 [bonding]
       [<ffffffff81553af7>] __dev_set_rx_mode+0x57/0xa0
       [<ffffffff81557ff8>] __dev_mc_add+0x58/0x70
       [<ffffffff81558020>] dev_mc_add+0x10/0x20
       [<ffffffff8161e26e>] igmp6_group_added+0x18e/0x1d0
       [<ffffffff81186f76>] ? kmem_cache_alloc_trace+0x236/0x260
       [<ffffffff8161f80f>] ipv6_dev_mc_inc+0x29f/0x320
       [<ffffffff8161f9e7>] ipv6_sock_mc_join+0x157/0x260
      ...
      
      Fix this by using RCU primitives.
      Reported-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Tested-by: NJoe Lawrence <joe.lawrence@stratus.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3241870
    • N
      bonding: Fix broken promiscuity reference counting issue · 5a0068de
      Neil Horman 提交于
      Recently grabbed this report:
      https://bugzilla.redhat.com/show_bug.cgi?id=1005567
      
      Of an issue in which the bonding driver, with an attached vlan encountered the
      following errors when bond0 was taken down and back up:
      
      dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
      device might be broken.
      
      The error occurs because, during __bond_release_one, if we release our last
      slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
      notification.  With an attached vlan, the vlan may see that the vlan and bond
      mac address were in sync, but no longer are.  This triggers a call to dev_uc_add
      and dev_set_rx_mode, which enables IFF_PROMISC on the bond device.  Then, when
      we complete __bond_release_one, we use the current state of the bond flags to
      determine if we should decrement the promiscuity of the releasing slave.  But
      since the bond changed promiscuity state during the release operation, we
      incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
      to begin with, causing the above error
      
      Fix is pretty simple, just cache the bonding flags at the start of the function
      and use those when determining the need to set promiscuity.
      
      This is also needed for the ALLMULTI flag
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Mark Wu <wudxw@linux.vnet.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Reported-by: NMark Wu <wudxw@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a0068de
  4. 29 9月, 2013 1 次提交
    • V
      bonding: correctly verify for the first slave in bond_enslave · 23c147e0
      Veaceslav Falico 提交于
      After commit 1f718f0f ("bonding: populate
      neighbour's private on enslave"), we've moved the actual 'linking' in the
      end of the function - so that, once linked, the slave is ready to be used,
      and is not still in the process of enslaving.
      
      However, 802.3ad verified if it's the first slave by looking at the
      
      if (bond_first_slave(bond) == new_slave)
      
      which, because we've moved the linking to the end, became broken - on the
      first slave bond_first_slave(bond) returns NULL.
      
      Fix this by verifying if the prev_slave, that equals bond_last_slave(), is
      actually populated - if it is - then it's not the first slave, and vice
      versa.
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23c147e0
  5. 27 9月, 2013 11 次提交
  6. 16 9月, 2013 1 次提交
  7. 12 9月, 2013 1 次提交
  8. 04 9月, 2013 4 次提交
  9. 30 8月, 2013 5 次提交
  10. 26 8月, 2013 1 次提交
  11. 09 8月, 2013 2 次提交
  12. 06 8月, 2013 4 次提交
  13. 03 8月, 2013 1 次提交
  14. 02 8月, 2013 4 次提交
    • N
      bonding: initial RCU conversion · 278b2083
      nikolay@redhat.com 提交于
      This patch does the initial bonding conversion to RCU. After it the
      following modes are protected by RCU alone: roundrobin, active-backup,
      broadcast and xor. Modes ALB/TLB and 3ad still acquire bond->lock for
      reading, and will be dealt with later. curr_active_slave needs to be
      dereferenced via rcu in the converted modes because the only thing
      protecting the slave after this patch is rcu_read_lock, so we need the
      proper barrier for weakly ordered archs and to make sure we don't have
      stale pointer. It's not tagged with __rcu yet because there's still work
      to be done to remove the curr_slave_lock, so sparse will complain when
      rcu_assign_pointer and rcu_dereference are used, but the alternative to use
      rcu_dereference_protected would've created much bigger code churn which is
      more difficult to test and review. That will be converted in time.
      
      1. Active-backup mode
       1.1 Perf recording while doing iperf -P 4
        - old bonding: iperf spent 0.55% in bonding, system spent 0.29% CPU
                       in bonding
        - new bonding: iperf spent 0.29% in bonding, system spent 0.15% CPU
                       in bonding
       1.2. Bandwidth measurements
        - old bonding: 16.1 gbps consistently
        - new bonding: 17.5 gbps consistently
      
      2. Round-robin mode
       2.1 Perf recording while doing iperf -P 4
        - old bonding: iperf spent 0.51% in bonding, system spent 0.24% CPU
                       in bonding
        - new bonding: iperf spent 0.16% in bonding, system spent 0.11% CPU
                       in bonding
       2.2 Bandwidth measurements
        - old bonding: 8 gbps (variable due to packet reorderings)
        - new bonding: 10 gbps (variable due to packet reorderings)
      
      Of course the latency has improved in all converted modes, and moreover
      while
      doing enslave/release (since it doesn't affect tx anymore).
      
      Also I've stress tested all modes doing enslave/release in a loop while
      transmitting traffic.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      278b2083
    • N
      bonding: factor out slave id tx code and simplify xmit paths · 15077228
      Nikolay Aleksandrov 提交于
      I factored out the tx xmit code which relies on slave id in
      bond_xmit_slave_id. It is global because later it can be used also in
      3ad mode xmit. Unnecessary obvious comments are removed. Active-backup
      mode is simplified because bond_dev_queue_xmit always consumes the skb.
      bond_xmit_xor becomes one line because of bond_xmit_slave_id.
      bond_for_each_slave_from is not used in bond_xmit_slave_id because later
      when RCU is used we can avoid important race condition by using standard
      rculist routines.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15077228
    • N
      bonding: simplify broadcast_xmit function · 78a646ce
      Nikolay Aleksandrov 提交于
      We don't need to start from the curr_active_slave as the frame will be
      sent to all eligible slaves anyway, so we remove the unnecessary local
      variables, checks and comments, and make it use the standard list API.
      This has the nice side-effect that later when it's converted to RCU
      a race condition will be avoided which could lead to double packet tx.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78a646ce
    • N
      bonding: remove unnecessary read_locks of curr_slave_lock · 71bc3b2d
      nikolay@redhat.com 提交于
      In all the cases we already hold bond->lock for reading, so the slave
      can't get away and the check != NULL is sufficient. curr_active_slave
      can still change after the read_lock is unlocked prior to use of the
      dereferenced value, so there's no need for it. It either contains a
      valid slave which we use (and can't get away), or it is NULL which is
      checked.
      In some places the read_lock of curr_slave_lock was left because we need
      it not to change while performing some action (e.g. syncing current
      active slave's addresses, sending ARP requests through the active slave)
      such cases will be dealt with individually while converting to RCU.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71bc3b2d