1. 17 3月, 2009 14 次提交
  2. 15 3月, 2009 24 次提交
  3. 14 3月, 2009 2 次提交
    • G
      ppp: ppp_mp_explode() redesign · 9c705260
      Gabriele Paoloni 提交于
      I found the PPP subsystem to not work properly when connecting channels
      with different speeds to the same bundle.
      
      Problem Description:
      
      As the "ppp_mp_explode" function fragments the sk_buff buffer evenly
      among the PPP channels that are connected to a certain PPP unit to
      make up a bundle, if we are transmitting using an upper layer protocol
      that requires an Ack before sending the next packet (like TCP/IP for
      example), we will have a bandwidth bottleneck on the slowest channel
      of the bundle.
      
      Let's clarify by an example. Let's consider a scenario where we have
      two PPP links making up a bundle: a slow link (10KB/sec) and a fast
      link (1000KB/sec) working at the best (full bandwidth). On the top we
      have a TCP/IP stack sending a 1000 Bytes sk_buff buffer down to the
      PPP subsystem. The "ppp_mp_explode" function will divide the buffer in
      two fragments of 500B each (we are neglecting all the headers, crc,
      flags etc?.). Before the TCP/IP stack sends out the next buffer, it
      will have to wait for the ACK response from the remote peer, so it
      will have to wait for both fragments to have been sent over the two
      PPP links, received by the remote peer and reconstructed. The
      resulting behaviour is that, rather than having a bundle working
      @1010KB/sec (the sum of the channels bandwidths), we'll have a bundle
      working @20KB/sec (the double of the slowest channels bandwidth).
      
      
      Problem Solution:
      
      The problem has been solved by redesigning the "ppp_mp_explode"
      function in such a way to make it split the sk_buff buffer according
      to the speeds of the underlying PPP channels (the speeds of the serial
      interfaces respectively attached to the PPP channels). Referring to
      the above example, the redesigned "ppp_mp_explode" function will now
      divide the 1000 Bytes buffer into two fragments whose sizes are set
      according to the speeds of the channels where they are going to be
      sent on (e.g .  10 Byets on 10KB/sec channel and 990 Bytes on
      1000KB/sec channel).  The reworked function grants the same
      performances of the original one in optimal working conditions (i.e. a
      bundle made up of PPP links all working at the same speed), while
      greatly improving performances on the bundles made up of channels
      working at different speeds.
      Signed-off-by: NGabriele Paoloni <gabriele.paoloni@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c705260
    • T
      tulip: Fix for MTU problems with 802.1q tagged frames · 1f8ae0a2
      Tomasz Lemiech 提交于
      The original patch was submitted last year but wasn't discussed or applied
      because of missing maintainer's CCs. I only fixed some formatting errors,
      but as I saw tulip is very badly formatted and needs further work.
      
      Original description:
      This patch fixes MTU problem, which occurs when using 802.1q VLANs. We
      should allow receiving frames of up to 1518 bytes in length, instead of
      1514.
      
      Based on patch written by Ben McKeegan for 2.4.x kernels. It is archived
      at http://www.candelatech.com/~greear/vlan/howto.html#tulip
      I've adjusted a few things to make it apply on 2.6.x kernels.
      
      Tested on D-Link DFE-570TX quad-fastethernet card.
      Signed-off-by: NTomasz Lemiech <szpajder@staszic.waw.pl>
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Signed-off-by: NBen McKeegan <ben@netservers.co.uk>
      Acked-by: NGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f8ae0a2
反馈
建议
客服 返回
顶部