netdev
[Top] [All Lists]

RE: Intel and TOE in the news

To: "'Andi Kleen'" <ak@xxxxxx>, "'Leonid Grossman'" <leonid.grossman@xxxxxxxxxxxx>
Subject: RE: Intel and TOE in the news
From: "Leonid Grossman" <leonid.grossman@xxxxxxxxxxxx>
Date: Tue, 22 Feb 2005 14:17:35 -0800
Cc: "'Stephen Hemminger'" <shemminger@xxxxxxxx>, <hadi@xxxxxxxxxx>, "'rick jones'" <rick.jones2@xxxxxx>, <netdev@xxxxxxxxxxx>, "'Alex Aizman'" <alex@xxxxxxxxxxxx>
In-reply-to: <20050222214345.GA51890@xxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Thread-index: AcUZJ5aKNY2SnIbbSjKoIMOxEPmFPQABKODQ
 

> -----Original Message-----
> From: Andi Kleen [mailto:ak@xxxxxx] 
> Sent: Tuesday, February 22, 2005 1:44 PM
> To: Leonid Grossman
> Cc: 'Stephen Hemminger'; hadi@xxxxxxxxxx; 'rick jones'; 
> netdev@xxxxxxxxxxx; 'Alex Aizman'
> Subject: Re: Intel and TOE in the news
> 
> > 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. 

Sounds good, thanks! We should be OK then.
Leonid
> 
> > > 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>