Yunsong (Roamer) Lu wrote:
>> This is the problem. For every changes in a protocol,
>> somehow the LSO may need to be changed to accommodate
> I'm saying it's possible to do so if it's *really* valuable. But I don't
> see the value of supporting such MTU adjustment with LSO at all. See my
> reply below.
I think you are missing the key issue here, that
LSO is not a good idea because the transport
has very few control on what it will do to the
packet. And as in the current form, for every
changes the supported protocols (which is a
limited number) may have, we need to "extend" the
LSO implementation. As I said in a previous mail,
the designer of LSO just thought that something
never changes, which is simply false.
> Basic SOFT LSO functions as a LSO simulator that parse the over-sized
> packet to a chain of MTU-sized packets.
Into some fixed TCP segments and TCP has no
control whatsoever on the header. Correct? This
is the problem.
> Actually, this could be easily handled inside TCP.
> Do LSO with unique MSS within each transmission, and MSS can be adjusted
> immediately for the next transmissions. Keep this in mind: LSO can
> benefit performance whenever there is >MSS payload that could be sent
> with the same MSS size.
I think you misunderstood the example here.
Let me give a concrete example. TCP has 64KB
worth of data to send and the congestion window
allows it to send 4380 bytes. The whole point
of LSO is that TCP can now send down the 4380
bytes all at the same time. The hardware (or
software) will break them up into fixed size
segments according to a given value. Let's say
it is 730 bytes. So the hardware will break
them up into 6 segments. But the problem is
that TCP wants to do PMTUd now. And it wants
to send 1 1460 bytes segment follows by 4 730
bytes segments. To do that with the current LSO,
TCP needs to do two sends, which just *defeats*
the whole point of LSO.
Note that this is just a simple example to
illustrate the flaws of LSO, in addition to the
other examples I gave in previous email. If we
want to fix this, we need to allow the transports
to have complete control on the header and payload.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
