On 8/6/06, jamal <[EMAIL PROTECTED]> wrote:
Q: Do you know the historical context of why TX_WAKE_THRESHOLD and E1000_TX_WEIGHT are hard-coded (and not for example related to the size of the ring)? Jesse? Otherwise i would like to submit a patch for the above. eventually probably even allow the setting via ethtool.
Yeah those are both created by me, interestingly up until a couple of releases ago we had neither. To answer your question of context, I noticed very specific problems and fixed them with the simplest method that worked. I figure we can address it as time goes on (like we are now) with improvements. As for specifics, for TX_WAKE_THRESHOLD, i noticed that we were starting the queue after every packet was cleaned, so when the ring went full there was a lot of queue thrash. tg3 seemed to fix it in a smart way and so I did a similar fix. Note we should have at least MAX_SKB_FRAGS (usually 32) + a few descriptors free before we should start the tx again, otherwise we run the risk of a maximum fragmented packet being unable to fit in the tx ring. now, for E1000_TX_WEIGHT, that was more of an experiment as i noticed we could stay in transmit clean up forEVER (okay not literally) which would really violate our NAPI timeslice. I messed with some values and 64 didn't really seem like too bad a compromise (it does slow things down just a tad in the general case) while really helping a couple of tests where there were lots of outstanding transmits happening at the same time as lots of receives. This need for a tx weight is yet another global (design) problem with NAPI enabled drivers, but someday I'll try to document some of the issues I've seen. Jesse - 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
