All other things being equal, it is better not to put packets into the
network faster than it can drain them out. Large bursts increase delay
variation, and increase the probability that two or more packets in a
connection will be dropped within an RTT (not every box is implementing
AQM yet). Ne
LRO will just stop accumulating when out-of-sequence data arrives.
Nothing complicated at all.
Unless the NIC keeps state, it is not always able to know if data is out of
sequence.
The LRO timing is not complicated, the packet limit is simply a
linearly increasing value that just makes sure
How do you intend on avoiding huge stretch ACKs?
The implication is that stretch ACKs are bad, which is wrong.
Oh yes, that's right, you're the same person who earlier in this
thread tried to teach us that bursty TCPs are non-standard :-)
Are you saying that burstiness is not an issue?
There i
You could also tweak the LRO timeout in a similar fashion based upon
traffic patterns as well. In fact, extremely sophisticated things can
be done here to deal with the LRO timing as seen on WAN vs. LAN
streams.
The accurate statement is "extremely complicated things need to be done here
to de
Date: Sat, 20 Aug 2005 21:55:22 -0700 (PDT)
I bet the tricks that we hack into the TCP/IP stack for LSO and for
LRO will turn out to be more difficult to maintain than the proposed
TOE hooks.
LRO is going to be mostly transparent.
How do you intend on avoiding huge stretch ACKs?
As far as
Christoph Lameter wrote:
On Sat, 20 Aug 2005, David S. Miller wrote:
But by in large, if a stateless alternative ever exists to
get the same performance benefit as TOE, it will undoubtedly
be preferred by the Linux networking maintainers, by in large.
So you TOE guys are fighting more than an up
> But by in large, if a stateless alternative ever exists to
> get the same performance benefit as TOE, it will undoubtedly
> be preferred by the Linux networking maintainers, by in large.
> So you TOE guys are fighting more than an uphill battle.
Nevertheless, this constitutes a reasonable starti
> TSO and TOE both help significantly with the per-packet costs. They
are
> effectively equivalent here to using larger packets. Doing zero-copy
and
> checksum offloading helps with the per-byte costs, and is possible
today
> with stock Linux, and I believe most TOE implementations do. But TO
> > We are discussing something that is not useful for todays
> network load
> > and not standardized. TOE is the only answer to offloading
> transfers of
> > data encountered in contemporary networks.
>
> It is talk like this that makes me want to not participate in such
> threads "TOE i
> Each TOE implementation is locked in time by the speed of the NIC.
> Given time, the network stack will -exceed- the speed of
> today's TOE NICs.
>
> You can see this with 100mbps TOE NICs, which are slower than today's
> software net stack, with today's software net stack being more
> featu
We all agree that there is a problem, and each is offering a solution. The
point is that claiming stateless offload is ideal and that TOE is just bad
is not objective. Each has its pros and cons. The performance benefits of
TOE have been demonstrated for many real applications, and we've seen qu
The is no RFC violated by being "bursty". Show me the RFC where TCP
burstiness is "standardized". This is yet another strawman.
You surely know this is a recurring theme in all congestion control RFCs
(RFC2581 in particular),
as well as in the "Known TCP Implementation Problems" RFC2525.
-
> With stateless offloading schemes? Absolutely it is possible.
>
> Even without stateless offloading, if it can't be done today, then
> they will soon.
>
> This is what has always happened in the past, people were preaching
> for TOE back when 100Mbit ethernet was "new and fast". But you
> cer
13 matches
Mail list logo
