On Thu, 18 Dec 2008, Herbert Xu wrote:

On Thu, Dec 18, 2008 at 08:29:07AM +1100, Herbert Xu wrote:

quoted

quoted

I.e. we set URG and urg_ptr to fake scb->seq + 0xFFFF only when:

	after(scb->seq + 0xFFFF, tp->snd_nxt)

My brains are rusty, so take this critically. :-)

Indeed that's a great idea!

OK, I think this is what we should do:

1) Fix fresh transmissions of urgent mode as Alexey suggested.

This is the safest way of ensuring that the urgent notification
is not delayed.  This is still not as "fast" as the BSD behaviour
but it is much safer with respect to broken^H^H^H^H^H^Hlegacy
applications.

2) Continue to use the current test for retransmissions.

3) Apply my original GSO patch and revert the existing URG fixes.

With Alexey's fix, the scenario that Ilpo identified would only
occur on retransmissions.  As we disable TSO on retransmissions,
it no longer affects my patch.

No, would you use that 0xffff hack with gso you would create even worse 
problem in case of reordering / losses. And that's just because the very 
scenario still remains fully unsolved. I'm not sure if you understood my 
scenario at all (I was hopeful that you did :-))? It's basically that 
(with the terms of this hack) some segments in a super-skb would need to 
set 0xffff while some < 0xffff. ...But you just can't send too large urg 
ptr in any segment or you're asking for trouble.

Also, I think even without gso but with reordering / enough losses will 
make it possible that not-yet-sent condition of Alexey's proposal (it's 
techically not-yet-received) will no longer hold from _the receiver's_ 
point of view and havoc breaks loose.


-- 
 i.