| To: | Leonid Grossman <leonid.grossman@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Intel and TOE in the news |
| From: | Andi Kleen <ak@xxxxxx> |
| Date: | 22 Feb 2005 22:43:45 +0100 |
| Date: | Tue, 22 Feb 2005 22:43:45 +0100 |
| Cc: | "'Stephen Hemminger'" <shemminger@xxxxxxxx>, hadi@xxxxxxxxxx, "'rick jones'" <rick.jones2@xxxxxx>, netdev@xxxxxxxxxxx, "'Alex Aizman'" <alex@xxxxxxxxxxxx> |
| In-reply-to: | <200502222052.j1MKqaDD022407@guinness.s2io.com> |
| References: | <20050222180711.GA84438@muc.de> <200502222052.j1MKqaDD022407@guinness.s2io.com> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.4.1i |
> TSO case is probably different - TSO hardware just sets PSH on the last > fragment only (and only if the flag was set on the original large tx > packet). Receiver doesn't really know if the sender is TSO-capable or not > and will ACK the same way - will it not? > Anyway, with LRO we do change rx packet count so affecting parts of TCP that > depend on packet count is indeed a concern; I guess we'll find out soon > enough whether there are real issues with the approach :-) Linux doesn't depend on packet count; it keeps an estimate called rcv_mss about the biggest seen packet size and acks every 2*rcv_mss worth of data. Your scheme would likely result in acking every two of your large packets as soon as the connection is out of "quickack" mode. So there would be on wire differences. > > Linux TCP RX path didn't care about PSH last time I checked. Actually it does for measuring the rcv_mss for very small MTUs. Shouldn't matter in practice though. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Intel and TOE in the news, Rick Jones |
|---|---|
| Next by Date: | [RFT] BIC TCP delayed ack compensation, Stephen Hemminger |
| Previous by Thread: | RE: Intel and TOE in the news, Leonid Grossman |
| Next by Thread: | RE: Intel and TOE in the news, Leonid Grossman |
| Indexes: | [Date] [Thread] [Top] [All Lists] |