Cathy Zhou wrote: > Eric Cheng wrote: >> Peter Memishian wrote: >>> > > Ouch. One possibility would be to to let the messages pile up and >>> > > periodically (maybe once a second when flow controlled?) have a >>> reaper >>> > > thread run, tally the number of messages, and free the part of >>> the chain >>> > > that's over the limit. This way, the messages are only counted >>> e.g. once >>> > > a second instead of once every call to dld_tx_enqueue(). (It >>> could also >>> > > move the messages that it's already counted to a separate message >>> queue, >>> > > so that subsequent counts would just need to process the newly >>> received >>> > > messages.) >>> > > > This solution sounds feasible. I will try that out and get >>> back with the > result. >>> >>> Cool. Eric: if this performs well, is it otherwise acceptable? >>> >> >> that sounds fine. but is once a second too infrequent? I suspect you >> could pile up lots of data within a second, potentially causing some >> transient hangs. doing this too frequently is also not ideal because >> you'd lose the performance advantage. I guess we need more >> experimentation here. >> >> I thought of another idea. since the majority of the chain-walking is >> caused by spurious wakeups of dld_wsrv() by dld_tx_single()-> >> dld_tx_enqueue(), and that dls_tx() would most likely fail inside >> dld_wsrv(), we could cache the value of ds_tx_cnt, call dls_tx() and >> compare its return value to the mp passed to it; if they are the same, >> that means the chain hasn't changed and we could reuse the cached count. >> the actual dsp->ds_tx_cnt could have been updated by someone else. we >> just have to add it to the cached value. this should save a lot of >> redundant chain walking. dld_tx_enqueue() would probably need an extra >> length parameter. >> > This is a better idea. > > I tried this approach and found that with this change, the performance can > be the same as the one if the message counting is removed. > Another follow-up.
I tried both approaches out (your suggestion and Meem's timer suggestion), and fount that we get the best performance when combine these two together, and the timer has to be set to 1 second. For whoever is interested, here is the webrev: http://jurassic.eng/net/aquila.prc/export/home/cathy/clearview/webrev_tcp/ Sorry for those who do not have SWAN access. Let me know if you are interested, then I'll post a external link later. Thanks - Cathy
