Hi Beyers, > Thanks, that makes perfect sense. Schedule the task in the timer, and > assign the task (element) to the same thread as the pull path with > StaticThreadSched. > > I'm just playing around with different configs to find the most optimum > loss-free packet receive-only rate, where latency on the pull path is of > no concern. > > Do you think in theory a MT click config where one thread is dedicated > to device polling and queueing, and the second thread handles the pull > path that always ends in a Discard is the right way to go? Anyone got > any alternative approaches?
This sounds like a reasonable approach!... It does sound almost like you want one CPU to run click "greedily", while the other goes about Click+all other work... Unfortunately greediness is currently broken on 2.6, I think. Eddie _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
