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. eric
