1. 01 12月, 2010 3 次提交
  2. 30 11月, 2010 1 次提交
    • S
      sctp: kill unused macros in head file · 49b4a654
      Shan Wei 提交于
      1. SCTP_CMD_NUM_VERBS,SCTP_CMD_MAX
      These two macros have never been used for several years since v2.6.12-rc2.
      
      2.sctp_port_rover,sctp_port_alloc_lock
      The commit 063930 abandoned global variables of port_rover and port_alloc_lock,
      but still keep two macros to refer to them.
      So, remove them now.
      
      commit 06393009
      Author: Stephen Hemminger <shemminger@linux-foundation.org>
      Date:   Wed Oct 10 17:30:18 2007 -0700
      
          [SCTP]: port randomization
      Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49b4a654
  3. 29 11月, 2010 3 次提交
  4. 28 11月, 2010 1 次提交
    • T
      rtnl: make link af-specific updates atomic · cf7afbfe
      Thomas Graf 提交于
      As David pointed out correctly, updates to af-specific attributes
      are currently not atomic. If multiple changes are requested and
      one of them fails, previous updates may have been applied already
      leaving the link behind in a undefined state.
      
      This patch splits the function parse_link_af() into two functions
      validate_link_af() and set_link_at(). validate_link_af() is placed
      to validate_linkmsg() check for errors as early as possible before
      any changes to the link have been made. set_link_af() is called to
      commit the changes later.
      
      This method is not fail proof, while it is currently sufficient
      to make set_link_af() inerrable and thus 100% atomic, the
      validation function method will not be able to detect all error
      scenarios in the future, there will likely always be errors
      depending on states which are f.e. not protected by rtnl_mutex
      and thus may change between validation and setting.
      
      Also, instead of silently ignoring unknown address families and
      config blocks for address families which did not register a set
      function the errors EAFNOSUPPORT respectively EOPNOSUPPORT are
      returned to avoid comitting 4 out of 5 update requests without
      notifying the user.
      Signed-off-by: NThomas Graf <tgraf@infradead.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf7afbfe
  5. 25 11月, 2010 6 次提交
  6. 23 11月, 2010 1 次提交
    • L
      cfg80211: Fix regulatory bug with multiple cards and delays · b2e253cf
      Luis R. Rodriguez 提交于
      When two cards are connected with the same regulatory domain
      if CRDA had a delayed response then cfg80211's own set regulatory
      domain would still be the world regulatory domain. There was a bug
      on cfg80211's logic such that it assumed that once you pegged a
      request as the last request it was already the currently set
      regulatory domain. This would mean we would race setting a stale
      regulatory domain to secondary cards which had the same regulatory
      domain since the alpha2 would match.
      
      We fix this by processing each regulatory request atomically,
      and only move on to the next one once we get it fully processed.
      In the case CRDA is not present we will simply world roam.
      
      This issue is only present when you have a slow system and the
      CRDA processing is delayed. Because of this it is not a known
      regression.
      
      Without this fix when a delay is present with CRDA the second card
      would end up with an intersected regulatory domain and not allow it
      to use the channels it really is designed for. When two cards with
      two different regulatory domains were inserted you'd end up
      rejecting the second card's regulatory domain request.
      This fails with mac80211_hswim's regtest=2 (two requests, same alpha2)
      and regtest=3 (two requests, different alpha2) module parameter
      options.
      
      This was reproduced and tested against mac80211_hwsim using this
      CRDA delayer:
      
             #!/bin/bash
             echo $COUNTRY >> /tmp/log
             sleep 2
             /sbin/crda.orig
      
      And these regulatory tests:
      
             modprobe mac80211_hwsim regtest=2
             modprobe mac80211_hwsim regtest=3
      Reported-by: NMark Mentovai <mark@moxienet.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Tested-by: NMark Mentovai <mark@moxienet.com>
      Tested-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b2e253cf
  7. 22 11月, 2010 1 次提交
  8. 19 11月, 2010 2 次提交
  9. 18 11月, 2010 3 次提交
  10. 17 11月, 2010 9 次提交
    • F
    • F
    • J
      mac80211: Add function to get probe request template for current AP · a619a4c0
      Juuso Oikarinen 提交于
      Chipsets with hardware based connection monitoring need to autonomically
      send directed probe-request frames to the AP (in the event of beacon loss,
      for example.)
      
      For the hardware to be able to do this, it requires a template for the frame
      to transmit to the AP, filled in with the BSSID and SSID of the AP, but also
      the supported rate IE's.
      
      This patch adds a function to mac80211, which allows the hardware driver to
      fetch this template after association, so it can be configured to the hardware.
      Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a619a4c0
    • B
      mac80211: Add antenna configuration · 15d96753
      Bruno Randolf 提交于
      Allow antenna configuration by calling driver's function for it.
      
      We disallow antenna configuration if the wiphy is already running, mainly to
      make life easier for 802.11n drivers which need to recalculate HT capabilites.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      15d96753
    • B
      cfg80211: Add nl80211 antenna configuration · afe0cbf8
      Bruno Randolf 提交于
      Allow setting of TX and RX antennas configuration via nl80211.
      
      The antenna configuration is defined as a bitmap of allowed antennas to use.
      This API can be used to mask out antennas which are not attached or should not
      be used for other reasons like regulatory concerns or special setups.
      
      Separate bitmaps are used for RX and TX to allow configuring different antennas
      for receiving and transmitting. Each bitmap is 32 bit long, each bit
      representing one antenna, starting with antenna 1 at the first bit. If an
      antenna bit is set, this means the driver is allowed to use this antenna for RX
      or TX respectively; if the bit is not set the hardware is not allowed to use
      this antenna.
      
      Using bitmaps has the benefit of allowing for a flexible configuration
      interface which can support many different configurations and which can be used
      for 802.11n as well as non-802.11n devices. Instead of relying on some hardware
      specific assumptions, drivers can use this information to know which antennas
      are actually attached to the system and derive their capabilities based on
      that.
      
      802.11n devices should enable or disable chains, based on which antennas are
      present (If all antennas belonging to a particular chain are disabled, the
      entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
      Antenna selection) should be calculated based on the available chains after
      applying the antenna masks. Should a 802.11n device have diversity antennas
      attached to one of their chains, diversity can be enabled or disabled based on
      the antenna information.
      
      Non-802.11n drivers can use the antenna masks to select RX and TX antennas and
      to enable or disable antenna diversity.
      
      While covering chainmasks for 802.11n and the standard "legacy" modes "fixed
      antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare,
      but useful configurations as follows:
      
      1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
      have a low gain antenna for TX in order to keep within the regulatory
      constraints and a high gain antenna for RX in order to receive weaker signals
      ("speak softly, but listen harder"). This can be useful for building long-shot
      outdoor links. Another usage of this setup is having a low-noise pre-amplifier
      on antenna 1 and a power amplifier on the other antenna. This way transmit
      noise is mostly kept out of the low noise receive channel.
      (This would be bitmaps: tx 1 rx 2).
      
      2) Another similar setup is: Use RX diversity on both antennas, but always send
      on antenna 1. Again that would allow us to benefit from a higher gain RX
      antenna, while staying within the legal limits.
      (This would be: tx 0 rx 3).
      
      3) And finally there can be special experimental setups in research and
      development even with pre 802.11n hardware where more than 2 antennas are
      available. It's good to keep the API simple, yet flexible.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      
      --
      v7:	Made bitmasks 32 bit wide and rebased to latest wireless-testing.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afe0cbf8
    • A
      mac80211: support hardware TX fragmentation offload · f23a4780
      Arik Nemtsov 提交于
      The lower driver is notified when the fragmentation threshold changes
      and upon a reconfig of the interface.
      
      If the driver supports hardware TX fragmentation, don't fragment
      packets in the stack.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f23a4780
    • E
      net: reorder struct sock fields · b178bb3d
      Eric Dumazet 提交于
      Right now, fields in struct sock are not optimally ordered, because each
      path (RX softirq, TX completion, RX user,  TX user) has to touch fields
      that are contained in many different cache lines.
      
      The really critical thing is to shrink number of cache lines that are
      used at RX softirq time : CPU handling softirqs for a device can receive
      many frames per second for many sockets. If load is too big, we can drop
      frames at NIC level. RPS or multiqueue cards can help, but better reduce
      latency if possible.
      
      This patch starts with UDP protocol, then additional patches will try to
      reduce latencies of other ones as well.
      
      At RX softirq time, fields of interest for UDP protocol are :
      (not counting ones in inet struct for the lookup)
      
      Read/Written:
      sk_refcnt   (atomic increment/decrement)
      sk_rmem_alloc & sk_backlog.len (to check if there is room in queues)
      sk_receive_queue
      sk_backlog (if socket locked by user program)
      sk_rxhash
      sk_forward_alloc
      sk_drops
      
      Read only:
      sk_rcvbuf (sk_rcvqueues_full())
      sk_filter
      sk_wq
      sk_policy[0]
      sk_flags
      
      Additional notes :
      
      - sk_backlog has one hole on 64bit arches. We can fill it to save 8
      bytes.
      - sk_backlog is used only if RX sofirq handler finds the socket while
      locked by user.
      - sk_rxhash is written only once per flow.
      - sk_drops is written only if queues are full
      
      Final layout :
      
      [1] One section grouping all read/write fields, but placing rxhash and
      sk_backlog at the end of this section.
      
      [2] One section grouping all read fields in RX handler
         (sk_filter, sk_rcv_buf, sk_wq)
      
      [3] Section used by other paths
      
      I'll post a patch on its own to put sk_refcnt at the end of struct
      sock_common so that it shares same cache line than section [1]
      
      New offsets on 64bit arch :
      
      sizeof(struct sock)=0x268
      offsetof(struct sock, sk_refcnt)  =0x10
      offsetof(struct sock, sk_lock)    =0x48
      offsetof(struct sock, sk_receive_queue)=0x68
      offsetof(struct sock, sk_backlog)=0x80
      offsetof(struct sock, sk_rmem_alloc)=0x80
      offsetof(struct sock, sk_forward_alloc)=0x98
      offsetof(struct sock, sk_rxhash)=0x9c
      offsetof(struct sock, sk_rcvbuf)=0xa4
      offsetof(struct sock, sk_drops) =0xa0
      offsetof(struct sock, sk_filter)=0xa8
      offsetof(struct sock, sk_wq)=0xb0
      offsetof(struct sock, sk_policy)=0xd0
      offsetof(struct sock, sk_flags) =0xe0
      
      Instead of :
      
      sizeof(struct sock)=0x270
      offsetof(struct sock, sk_refcnt)  =0x10
      offsetof(struct sock, sk_lock)    =0x50
      offsetof(struct sock, sk_receive_queue)=0xc0
      offsetof(struct sock, sk_backlog)=0x70
      offsetof(struct sock, sk_rmem_alloc)=0xac
      offsetof(struct sock, sk_forward_alloc)=0x10c
      offsetof(struct sock, sk_rxhash)=0x128
      offsetof(struct sock, sk_rcvbuf)=0x4c
      offsetof(struct sock, sk_drops) =0x16c
      offsetof(struct sock, sk_filter)=0x198
      offsetof(struct sock, sk_wq)=0x88
      offsetof(struct sock, sk_policy)=0x98
      offsetof(struct sock, sk_flags) =0x130
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b178bb3d
    • E
      udp: use atomic_inc_not_zero_hint · c31504dc
      Eric Dumazet 提交于
      UDP sockets refcount is usually 2, unless an incoming frame is going to
      be queued in receive or backlog queue.
      
      Using atomic_inc_not_zero_hint() permits to reduce latency, because
      processor issues less memory transactions.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c31504dc
    • J
      netlink: let nlmsg and nla functions take pointer-to-const args · 3654654f
      Jan Engelhardt 提交于
      The changed functions do not modify the NL messages and/or attributes
      at all. They should use const (similar to strchr), so that callers
      which have a const nlmsg/nlattr around can make use of them without
      casting.
      
      While at it, constify a data array.
      Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3654654f
  11. 16 11月, 2010 5 次提交
  12. 13 11月, 2010 1 次提交
  13. 12 11月, 2010 3 次提交
    • D
      ipv4: Make rt->fl.iif tests lest obscure. · c7537967
      David S. Miller 提交于
      When we test rt->fl.iif against zero, we're seeing if it's
      an output or an input route.
      
      Make that explicit with some helper functions.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7537967
    • E
      net: get rid of rtable->idev · 72cdd1d9
      Eric Dumazet 提交于
      It seems idev field in struct rtable has no special purpose, but adding
      extra atomic ops.
      
      We hold refcounts on the device itself (using percpu data, so pretty
      cheap in current kernel).
      
      infiniband case is solved using dst.dev instead of idev->dev
      
      Removal of this field means routing without route cache is now using
      shared data, percpu data, and only potential contention is a pair of
      atomic ops on struct neighbour per forwarded packet.
      
      About 5% speedup on routing test.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72cdd1d9
    • E
      neigh: reorder struct neighbour · 46b13fc5
      Eric Dumazet 提交于
      It is important to move nud_state outside of the often modified cache
      line (because of refcnt), to reduce false sharing in neigh_event_send()
      
      This is a followup of commit 0ed8ddf4 (neigh: Protect neigh->ha[]
      with a seqlock)
      
      This gives a 7% speedup on routing test with IP route cache disabled.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      46b13fc5
  14. 11 11月, 2010 1 次提交