1. 14 4月, 2012 2 次提交
    • D
      net/garp: fix GID rbtree ordering · 6f66cdc3
      David Ward 提交于
      The comparison operators were backwards in both garp_attr_lookup and
      garp_attr_create, so the entire GID rbtree was in reverse order.
      (There was no practical side effect to this though, except that PDUs
      were sent with attributes listed in reverse order, which is still
      valid by the protocol. This change is only for clarity.)
      Signed-off-by: NDavid Ward <david.ward@ll.mit.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f66cdc3
    • D
      pppoatm: Fix excessive queue bloat · 9d02daf7
      David Woodhouse 提交于
      We discovered that PPPoATM has an excessively deep transmit queue. A
      queue the size of the default socket send buffer (wmem_default) is
      maintained between the PPP generic core and the ATM device.
      
      Fix it to queue a maximum of *two* packets. The one the ATM device is
      currently working on, and one more for the ATM driver to process
      immediately in its TX done interrupt handler. The PPP core is designed
      to feed packets to the channel with minimal latency, so that really
      ought to be enough to keep the ATM device busy.
      
      While we're at it, fix the fact that we were triggering the wakeup
      tasklet on *every* pppoatm_pop() call. The comment saying "this is
      inefficient, but doing it right is too hard" turns out to be overly
      pessimistic... I think :)
      
      On machines like the Traverse Geos, with a slow Geode CPU and two
      high-speed ADSL2+ interfaces, there were reports of extremely high CPU
      usage which could partly be attributed to the extra wakeups.
      
      (The wakeup handling could actually be made a whole lot easier if we
       stop checking sk->sk_sndbuf altogether. Given that we now only queue
       *two* packets ever, one wonders what the point is. As it is, you could
       already deadlock the thing by setting the sk_sndbuf to a value lower
       than the MTU of the device, and it'd just block for ever.)
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d02daf7
  2. 13 4月, 2012 38 次提交