1. 30 1月, 2009 1 次提交
    • H
      gro: Avoid copying headers of unmerged packets · 86911732
      Herbert Xu 提交于
      Unfortunately simplicity isn't always the best.  The fraginfo
      interface turned out to be suboptimal.  The problem was quite
      obvious.  For every packet, we have to copy the headers from
      the frags structure into skb->head, even though for 99% of the
      packets this part is immediately thrown away after the merge.
      
      LRO didn't have this problem because it directly read the headers
      from the frags structure.
      
      This patch attempts to address this by creating an interface
      that allows GRO to access the headers in the first frag without
      having to copy it.  Because all drivers that use frags place the
      headers in the first frag this optimisation should be enough.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86911732
  2. 27 1月, 2009 1 次提交
    • D
      tcp: Fix length tcp_splice_data_recv passes to skb_splice_bits. · 9fa5fdf2
      Dimitris Michailidis 提交于
      tcp_splice_data_recv has two lengths to consider: the len parameter it
      gets from tcp_read_sock, which specifies the amount of data in the skb,
      and rd_desc->count, which is the amount of data the splice caller still
      wants.  Currently it passes just the latter to skb_splice_bits, which then
      splices min(rd_desc->count, skb->len - offset) bytes.
      
      Most of the time this is fine, except when the skb contains urgent data.
      In that case len goes only up to the urgent byte and is less than
      skb->len - offset.  By ignoring len tcp_splice_data_recv may a) splice
      data tcp_read_sock told it not to, b) return to tcp_read_sock a value > len.
      
      Now, tcp_read_sock doesn't handle used > len and leaves the socket in a
      bad state (both sk_receive_queue and copied_seq are bad at that point)
      resulting in duplicated data and corruption.
      
      Fix by passing min(rd_desc->count, len) to skb_splice_bits.
      Signed-off-by: NDimitris Michailidis <dm@chelsio.com>
      Acked-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fa5fdf2
  3. 15 1月, 2009 1 次提交
  4. 14 1月, 2009 1 次提交
    • W
      tcp: splice as many packets as possible at once · 33966dd0
      Willy Tarreau 提交于
      As spotted by Willy Tarreau, current splice() from tcp socket to pipe is not
      optimal. It processes at most one segment per call.
      This results in low performance and very high overhead due to syscall rate
      when splicing from interfaces which do not support LRO.
      
      Willy provided a patch inside tcp_splice_read(), but a better fix
      is to let tcp_read_sock() process as many segments as possible, so
      that tcp_rcv_space_adjust() and tcp_cleanup_rbuf() are called less
      often.
      
      With this change, splice() behaves like tcp_recvmsg(), being able
      to consume many skbs in one system call. With typical 1460 bytes
      of payload per frame, that means splice(SPLICE_F_NONBLOCK) can return
      16*1460 = 23360 bytes.
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33966dd0
  5. 09 1月, 2009 1 次提交
  6. 07 1月, 2009 2 次提交
  7. 05 1月, 2009 3 次提交
  8. 30 12月, 2008 1 次提交
  9. 16 12月, 2008 1 次提交
  10. 26 11月, 2008 2 次提交
  11. 17 11月, 2008 1 次提交
    • E
      net: Convert TCP & DCCP hash tables to use RCU / hlist_nulls · 3ab5aee7
      Eric Dumazet 提交于
      RCU was added to UDP lookups, using a fast infrastructure :
      - sockets kmem_cache use SLAB_DESTROY_BY_RCU and dont pay the
        price of call_rcu() at freeing time.
      - hlist_nulls permits to use few memory barriers.
      
      This patch uses same infrastructure for TCP/DCCP established
      and timewait sockets.
      
      Thanks to SLAB_DESTROY_BY_RCU, no slowdown for applications
      using short lived TCP connections. A followup patch, converting
      rwlocks to spinlocks will even speedup this case.
      
      __inet_lookup_established() is pretty fast now we dont have to
      dirty a contended cache line (read_lock/read_unlock)
      
      Only established and timewait hashtable are converted to RCU
      (bind table and listen table are still using traditional locking)
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ab5aee7
  12. 05 11月, 2008 1 次提交
  13. 03 11月, 2008 1 次提交
  14. 08 10月, 2008 2 次提交
    • I
      tcp: kill pointless urg_mode · 33f5f57e
      Ilpo Järvinen 提交于
      It all started from me noticing that this urgent check in
      tcp_clean_rtx_queue is unnecessarily inside the loop. Then
      I took a longer look to it and found out that the users of
      urg_mode can trivially do without, well almost, there was
      one gotcha.
      
      Bonus: those funny people who use urg with >= 2^31 write_seq -
      snd_una could now rejoice too (that's the only purpose for the
      between being there, otherwise a simple compare would have done
      the thing). Not that I assume that the rest of the tcp code
      happily lives with such mind-boggling numbers :-). Alas, it
      turned out to be impossible to set wmem to such numbers anyway,
      yes I really tried a big sendfile after setting some wmem but
      nothing happened :-). ...Tcp_wmem is int and so is sk_sndbuf...
      So I hacked a bit variable to long and found out that it seems
      to work... :-)
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33f5f57e
    • P
      net: wrap sk->sk_backlog_rcv() · c57943a1
      Peter Zijlstra 提交于
      Wrap calling sk->sk_backlog_rcv() in a function. This will allow extending the
      generic sk_backlog_rcv behaviour.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c57943a1
  15. 07 10月, 2008 1 次提交
  16. 26 7月, 2008 1 次提交
  17. 19 7月, 2008 1 次提交
  18. 18 7月, 2008 1 次提交
  19. 17 7月, 2008 9 次提交
  20. 03 7月, 2008 2 次提交
  21. 28 6月, 2008 1 次提交
  22. 13 6月, 2008 1 次提交
    • D
      tcp: Revert 'process defer accept as established' changes. · ec0a1966
      David S. Miller 提交于
      This reverts two changesets, ec3c0982
      ("[TCP]: TCP_DEFER_ACCEPT updates - process as established") and
      the follow-on bug fix 9ae27e0a
      ("tcp: Fix slab corruption with ipv6 and tcp6fuzz").
      
      This change causes several problems, first reported by Ingo Molnar
      as a distcc-over-loopback regression where connections were getting
      stuck.
      
      Ilpo Järvinen first spotted the locking problems.  The new function
      added by this code, tcp_defer_accept_check(), only has the
      child socket locked, yet it is modifying state of the parent
      listening socket.
      
      Fixing that is non-trivial at best, because we can't simply just grab
      the parent listening socket lock at this point, because it would
      create an ABBA deadlock.  The normal ordering is parent listening
      socket --> child socket, but this code path would require the
      reverse lock ordering.
      
      Next is a problem noticed by Vitaliy Gusev, he noted:
      
      ----------------------------------------
      >--- a/net/ipv4/tcp_timer.c
      >+++ b/net/ipv4/tcp_timer.c
      >@@ -481,6 +481,11 @@ static void tcp_keepalive_timer (unsigned long data)
      > 		goto death;
      > 	}
      >
      >+	if (tp->defer_tcp_accept.request && sk->sk_state == TCP_ESTABLISHED) {
      >+		tcp_send_active_reset(sk, GFP_ATOMIC);
      >+		goto death;
      
      Here socket sk is not attached to listening socket's request queue. tcp_done()
      will not call inet_csk_destroy_sock() (and tcp_v4_destroy_sock() which should
      release this sk) as socket is not DEAD. Therefore socket sk will be lost for
      freeing.
      ----------------------------------------
      
      Finally, Alexey Kuznetsov argues that there might not even be any
      real value or advantage to these new semantics even if we fix all
      of the bugs:
      
      ----------------------------------------
      Hiding from accept() sockets with only out-of-order data only
      is the only thing which is impossible with old approach. Is this really
      so valuable? My opinion: no, this is nothing but a new loophole
      to consume memory without control.
      ----------------------------------------
      
      So revert this thing for now.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec0a1966
  23. 12 6月, 2008 2 次提交
  24. 05 6月, 2008 1 次提交
  25. 21 4月, 2008 1 次提交