| To: | cfriesen@xxxxxxxxxxxxxxxxxx |
|---|---|
| Subject: | Re: bonding vs 802.3ad/Cisco EtherChannel link agregation |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Mon, 16 Sep 2002 14:17:30 -0700 (PDT) |
| Cc: | greearb@xxxxxxxxxxxxxxx, cacophonix@xxxxxxxxx, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <3D864B96.6D0D43F4@nortelnetworks.com> |
| References: | <3D8648AE.DD498ECE@nortelnetworks.com> <20020916.140453.72638827.davem@redhat.com> <3D864B96.6D0D43F4@nortelnetworks.com> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
From: Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx> Date: Mon, 16 Sep 2002 17:22:30 -0400 I did see those posts, but then I saw yours on how the linux receive end does the right thing with regards to reordering, and that confused me. It's a last ditch effort to keep receive performance on the TCP connection reasonable, it is not meant to be a normal mode of operation. The reordering detection in the TCP stack does not get you back to optimal receive performance, it simply can't. For one thing, all of the fast paths in the TCP input paths require that the packets arrive in order. If bonding did what you suggest, reordering would become the norm and that isn't going to be good for TCP input performance whether we have reordering detection logic or not. |
| Previous by Date: | Re: bonding vs 802.3ad/Cisco EtherChannel link agregation, Chris Friesen |
|---|---|
| Next by Date: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, todd-lkml |
| Previous by Thread: | Re: bonding vs 802.3ad/Cisco EtherChannel link agregation, Chris Friesen |
| Next by Thread: | Re: bonding vs 802.3ad/Cisco EtherChannel link agregation, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |