[Top] [All Lists]

RE: Intel and TOE in the news

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

> -----Original Message-----
> From: Andi Kleen [mailto:ak@xxxxxx] 
> Sent: Tuesday, February 22, 2005 10:07 AM
> To: Stephen Hemminger
> Cc: Leonid Grossman; hadi@xxxxxxxxxx; 'rick jones'; 
> netdev@xxxxxxxxxxx; 'Alex Aizman'
> Subject: Re: Intel and TOE in the news
> > Be careful, this may have the same problems that original 
> TSO code did.
> > Make sure and force the PUSH flag on these jumbo receives 
> or the TCP 
> > "every other segment" ACK logic will be busted.  There are 
> other parts of TCP
> > that depend on packet count as well and this inverse TSO 
> logic will break them.

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 TCP RX path didn't care about PSH last time I checked. 
> It should make no difference how PSH is set on RX or if it is 
> set at all. At least unless Leonid wants to run his driver on 
> Darwin too, but that would be someone else's problem.
> -Andi

<Prev in Thread] Current Thread [Next in Thread>