Doug Graham wrote: > On Tue, Aug 04, 2009 at 10:50:18AM -0400, Vlad Yasevich wrote: >>> I admit that I didn't study too closely exactly what >>> q->outstanding_bytes represents. I assumed >>> it meant the number of bytes that had been sent on the wire, but not yet >>> acknowledged. >>> Any bytes that were delayed because of Nagle would not be counted in >>> outstanding_bytes >>> (I assume). So the first send of 726 would get sent immediately and >>> counted in >>> outstanding_bytes. The second one would get delayed by Nagle and not >>> counted >>> in outstanding_bytes. All the later ones would also get delayed by >>> Nagle because >>> outstanding_bytes is still 726. >>> >>> I do think that using outstanding_bytes the way I did is probably an >>> ugly kludge, and >>> there's hopefully a better way. But the right way will probably involve >>> adding >>> some more state to each association (the snd.sml variable mentioned in >>> the minshall >>> draft at the very least). I'm not sure that using asoc->frag_point the >>> way I did is correct >>> either, because I think the frag_point can change during the lifetime of >>> an association. >> Using division in such a hot path is a non-starter to begin with, so we >> definitely need to find a better way. > > That thought crossed by mind too, although I didn't consider it as much > of a show-stopper as you do. 32 bit integer division isn't really all > that expensive on modern processors is it? The C compiler is probably > doing it in places as a result of pointer arithmetic anyway. > >> Using frag_point is not the right way to do it either since it's effected by >> MTU and user API. >> >> I think we can add something to sctp_outq structure to properly track this. > > I've pretty much convinced myself that Wei's original Nagle patch is fine > anyway. Just disable Nagle for large messages that need to be fragmented. > We can't do it blindly since the user may set a fragmentation point such that we'll send sub-MSS (for lack of a better term) segments. I need to look at this more closely. -vlad > --Doug. > -- > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
