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. Thanks - Cathy > > >
