> -----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
> > 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
> > :-)
> 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.
> > > 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.