1. 06 11月, 2005 1 次提交
  2. 06 9月, 2005 1 次提交
  3. 02 9月, 2005 2 次提交
  4. 30 8月, 2005 17 次提交
  5. 24 8月, 2005 1 次提交
    • D
      [TCP]: Unconditionally clear TCP_NAGLE_PUSH in skb_entail(). · 89ebd197
      David S. Miller 提交于
      Intention of this bit is to force pushing of the existing
      send queue when TCP_CORK or TCP_NODELAY state changes via
      setsockopt().
      
      But it's easy to create a situation where the bit never
      clears.  For example, if the send queue starts empty:
      
      1) set TCP_NODELAY
      2) clear TCP_NODELAY
      3) set TCP_CORK
      4) do small write()
      
      The current code will leave TCP_NAGLE_PUSH set after that
      sequence.  Unconditionally clearing the bit when new data
      is added via skb_entail() solves the problem.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89ebd197
  6. 09 7月, 2005 1 次提交
  7. 06 7月, 2005 3 次提交
    • D
      [TCP]: Move to new TSO segmenting scheme. · c1b4a7e6
      David S. Miller 提交于
      Make TSO segment transmit size decisions at send time not earlier.
      
      The basic scheme is that we try to build as large a TSO frame as
      possible when pulling in the user data, but the size of the TSO frame
      output to the card is determined at transmit time.
      
      This is guided by tp->xmit_size_goal.  It is always set to a multiple
      of MSS and tells sendmsg/sendpage how large an SKB to try and build.
      
      Later, tcp_write_xmit() and tcp_push_one() chop up the packet if
      necessary and conditions warrant.  These routines can also decide to
      "defer" in order to wait for more ACKs to arrive and thus allow larger
      TSO frames to be emitted.
      
      A general observation is that TSO elongates the pipe, thus requiring a
      larger congestion window and larger buffering especially at the sender
      side.  Therefore, it is important that applications 1) get a large
      enough socket send buffer (this is accomplished by our dynamic send
      buffer expansion code) 2) do large enough writes.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1b4a7e6
    • D
      [TCP]: Fix send-side cpu utiliziation regression. · b4e26f5e
      David S. Miller 提交于
      Only put user data purely to pages when doing TSO.
      
      The extra page allocations cause two problems:
      
      1) Add the overhead of the page allocations themselves.
      2) Make us do small user copies when we get to the end
         of the TCP socket cache page.
      
      It is still beneficial to purely use pages for TSO,
      so we will do it for that case.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4e26f5e
    • D
      [TCP]: Simplify SKB data portion allocation with NETIF_F_SG. · c65f7f00
      David S. Miller 提交于
      The ideal and most optimal layout for an SKB when doing
      scatter-gather is to put all the headers at skb->data, and
      all the user data in the page array.
      
      This makes SKB splitting and combining extremely simple,
      especially before a packet goes onto the wire the first
      time.
      
      So, when sk_stream_alloc_pskb() is given a zero size, make
      sure there is no skb_tailroom().  This is achieved by applying
      SKB_DATA_ALIGN() to the header length used here.
      
      Next, make select_size() in TCP output segmentation use a
      length of zero when NETIF_F_SG is true on the outgoing
      interface.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c65f7f00
  8. 24 6月, 2005 2 次提交
  9. 19 6月, 2005 5 次提交
  10. 14 6月, 2005 1 次提交
  11. 06 5月, 2005 1 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4