On Tue, 8 Aug 2006, Herbert Xu wrote: > > -#define E1000_TX_WEIGHT 64 > > - /* weight of a sort for tx, to avoid endless transmit > > cleanup */ > > - if (count++ == E1000_TX_WEIGHT) break; > > + /* avoid endless transmit cleanup */ > > + if (count++ == tx_ring->prunet) break; > > > > As you can see E1000_TX_WEIGHT threshold exists today and you are right > > if no TX interupts, packet arrivals or scheduled wakes happen the that > > descriptor that was not pruned will sit there forever (which is a bad > > thing for TCP). Are we in sync? > > If yes, what is the likelihood they will sit there forever? I think > > perhaps some TX interupts will happen, no? > > I thought this code is only used for NAPI so as long as work was done > it'll keep calling this.
yes, you're correct. > One thing I'm not sure about though is the time between it decides that > there is no work and the point where the interrupts are reenabled. e1000 only clears the interrupts when it reads ICR in e1000_intr (before scheduling napi poll) so any interrupts that occur while polling (and interrupts are disabled) will cause a new assertion once interrupts are re-enabled. Sometimes a little bit inefficient due to extra trips through poll, but guarantees never to miss an int. I'm open to creative ways to avoid this, but adding an I/O read in e1000_clean would be pretty yucky. > What if work arrives in that time and no work ever arrives after the > interrupts are turned on again? Does that mean the work will sit there > forever? nope, see above. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
