[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081225.171146.208898156.davem@davemloft.net>
Date: Thu, 25 Dec 2008 17:11:46 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: ilpo.jarvinen@...sinki.fi
Cc: herbert@...dor.apana.org.au, kuznet@....inr.ac.ru,
ptesarik@...e.cz, netdev@...r.kernel.org
Subject: Re: [PATCH] tcp: make urg+gso work for real this time
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Thu, 18 Dec 2008 21:45:13 +0200 (EET)
> 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.
Hmmm, since URG is relative it means that GSO (or in-hardware TSO)
would need to adjust the URG offset for each segment.
But if we stick this 0xffff thing there, it _can't_ do that properly
because it cannot know where the correct URG pointer actually is.
In fact, the straightforward URG offset adjust one would expect a TSO
engine to make would corrupt the URG pointer when we put this
"infinity" value there.
The URG pointer might be >= 0xffff from the initial sequence number
of the starting TSO segment, but the URG offset might be in range
of one of the non-initial MSS segmented frames.
Anyways, we skip TSO/GSO for any time URG is indicated making all of
this particular concern moot. ;-) But if at some point we want to
allow it, we'd need to consider this problem.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists