On Jun 29, 2017, at 01:14 PM, "address@hidden" <address@hidden> wrote:
Joel Cunningham wrote:
The idea of performing the split upon the first fire of the persist
timer seems a reasonable compromise
The downside is that for this to work, we'd have to start the persist
timer before receiving a zero window. Which is what we do now already
but which is a bit off the standard. Sending a split segment then seems
to me like only solving cases where otherwise the connection would get
stuck. You see I tend to shift positions here, but as arguments come to
mind...
I would imagine most of the time, the receiver would have a window
update before the timer fires, so the split doesn't end up happening muc
That was my initial thought, exactly.
What level of optimization would it take to be ok always doing the split? Is it copying the remainder payload that's the problem or more generally just doing re-segmentation?
I guess it's copying the data. You could argue that we could just
reference the remainder (much like the ip-frag code does) and wouldn't
have to copy, but then most zero-copy MACs have to memcpy anyway due to
bad alignment (I assume most DMAs nowadays have at least a 4-byte
alignment requirement so statistically, a 3:1 chance that such a
scatter-gather MAC has to memcpy).
This is all feeling however. I don't have numbers of what exactly this
would mean.
Given all this, I still think our current approach is the best. Splittin
segments when the persist timer expires would only mean more code.
Unless the complete window is < 4*MSS, I don't expect problems here...
By current approach, you mean continue with the early-zero-window behavior and implement the check suggested in comment #34/35?
I agree that none of the alternatives seem much simpler, though figuring out how to do the segment split in a performant manner would be nice
Joel