On Mon, 30 Jul 2007, David Miller wrote: > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> > Date: Mon, 30 Jul 2007 20:19:40 +0300 (EEST) > > > I'm not completely pleased with this solution because readability > > of the code is somewhat questionable as 'is_dupack' in SACK case > > is no longer about dupacks only but would mean something like > > 'lost_marker_work_todo' too... But because of Eifel stuff done > > in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to > > the if statement which seems attractive solution. Nevertheless, > > I didn't like adding another variable just for that either... :-) > > I don't mind the complex conditionals so much in loss > handling, they are almost inevitable. However I believe > they could be simplified as a lot of pieces of code ask > similar if not identical questions. > > We could ask several of these things up-front, regardless > of path we will take (reno, DSACK, reorder, FRTO, etc.) > and pass the answers along in a bitmask. We do that to > some extent already with how we analyze the retransmit > queue at the beginning of ACK processing.
That's true, ...and my thought too as I was thinking of adding FLAG_SND_UNA_ADVANCED (!= FLAG_DATA_ACKED) (or it's opposite as I haven't yet checked which way it is more useful). That could help in many places and probably reduces compare pressure here and there as the bitmask operation can be done in one compare where it now has to do two compares, one for snd_una and other for the flag. ...I'll keep an eye on other possible bits too... :-) -- i.
