I did some searching and found these two entries in some kernel change logs. I have no idea if it helps any but I figured it couldn't hurt to ask...
~ ChangeLog-2.6.28 ~ 11696 commit 33cf71cee14743185305c61625c4544885055733 11697 Author: Petr Tesarik <[email protected]> 11698 Date: Fri Nov 21 16:42:58 2008 -0800 11699 11700 tcp: Do not use TSO/GSO when there is urgent data 11701 11702 This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=12014 11703 11704 Since most (if not all) implementations of TSO and even the in-kernel 11705 software GSO do not update the urgent pointer when splitting a large 11706 segment, it is necessary to turn off TSO/GSO for all outgoing traffic 11707 with the URG pointer set. 11708 11709 Looking at tcp_current_mss (and the preceding comment) I even think 11710 this was the original intention. However, this approach is insufficient, 11711 because TSO/GSO is turned off only for newly created frames, not for 11712 frames which were already pending at the arrival of a message with 11713 MSG_OOB set. These frames were created when TSO/GSO was enabled, 11714 so they may be large, and they will have the urgent pointer set 11715 in tcp_transmit_skb(). 11716 11717 With this patch, such large packets will be fragmented again before 11718 going to the transmit routine. 11719 11720 As a side note, at least the following NICs are known to screw up 11721 the urgent pointer in the TCP header when doing TSO: 11722 11723 Intel 82566MM (PCI ID 8086:1049) 11724 Intel 82566DC (PCI ID 8086:104b) 11725 Intel 82541GI (PCI ID 8086:1076) 11726 Broadcom NetXtreme II BCM5708 (PCI ID 14e4:164c) 11727 11728 Signed-off-by: Petr Tesarik <[email protected]> 11729 Signed-off-by: David S. Miller <[email protected]> ~ ChangeLog-2.6.29 ~ 168533 commit ef711cf1d156428d4c2911b8c86c6ce90519dc45 168534 Author: Eric Dumazet <[email protected]> 168535 Date: Fri Nov 14 00:53:54 2008 -0800 168536 168537 net: speedup dst_release() 168538 168539 During tbench/oprofile sessions, I found that dst_release() was in third position. 168540 168541 CPU: Core 2, speed 2999.68 MHz (estimated) 168542 Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 168543 samples % symbol name 168544 483726 9.0185 __copy_user_zeroing_intel 168545 191466 3.5697 __copy_user_intel 168546 185475 3.4580 dst_release 168547 175114 3.2648 ip_queue_xmit 168548 153447 2.8608 tcp_sendmsg 168549 108775 2.0280 tcp_recvmsg 168550 102659 1.9140 sysenter_past_esp 168551 101450 1.8914 tcp_current_mss 168552 95067 1.7724 __copy_from_user_ll 168553 86531 1.6133 tcp_transmit_skb 168554 168555 Of course, all CPUS fight on the dst_entry associated with 127.0.0.1 168556 168557 Instead of first checking the refcount value, then decrement it, 168558 we use atomic_dec_return() to help CPU to make the right memory transaction 168559 (ie getting the cache line in exclusive mode) 168560 168561 dst_release() is now at the fifth position, and tbench a litle bit faster ;) 168562 168563 CPU: Core 2, speed 3000.1 MHz (estimated) 168564 Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 168565 samples % symbol name 168566 647107 8.8072 __copy_user_zeroing_intel 168567 258840 3.5229 ip_queue_xmit 168568 258302 3.5155 __copy_user_intel 168569 209629 2.8531 tcp_sendmsg 168570 165632 2.2543 dst_release 168571 149232 2.0311 tcp_current_mss 168572 147821 2.0119 tcp_recvmsg 168573 137893 1.8767 sysenter_past_esp 168574 127473 1.7349 __copy_from_user_ll 168575 121308 1.6510 ip_finish_output 168576 118510 1.6129 tcp_transmit_skb 168577 109295 1.4875 tcp_v4_rcv 168578 168579 Signed-off-by: Eric Dumazet <[email protected]> 168580 Signed-off-by: David S. Miller <[email protected]> ** Bug watch added: Linux Kernel Bug Tracker #12014 http://bugzilla.kernel.org/show_bug.cgi?id=12014 -- "Kernel unaligned access at TPC" causing network/system to become slow and/or unresponsive https://bugs.launchpad.net/bugs/569610 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
