On 11/06/15 09:50, Luigi Rizzo wrote:
On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky <h...@selasky.org> wrote:
On 11/06/15 01:08, Rasool Al-Saadi wrote:
On Thursday, 5 November 2015 8:53 PM, Hans Petter Selasky wrote:
On 11/05/15 00:44, Rasool Al-Saadi wrote:
...
Removing C_HARDCLOCK reduces the problem but doesn't solve it completely.
However, removing C_DIRECT_EXEC instead solves the problem (but
occasionally very small spike(s) appears in high hz values).
I mentioned in my first email that removing these flags makes the issue to
disappear. But what the effects of removing these flags? If it cause timing
issue to Dummynet, why we should use them?
Hi,
The C_DIRECT_EXEC flag reduces task switching overhead, that you don't have
to wakeup a thread to wakeup the dummynet worker thread. It affects timing.
Hans,
thanks for the explanation.
Can you clarify the behaviour of C_DIRECT_EXEC ?
Does this mean that the task is run within some common
thread instead of a dedicated one ?
Hi Luigi,
C_DIRECT_EXEC means that the timer callback is executed directly from
the fast interrupt filter of the timer or IPI.
If so, for this type of task (dummynet may run at high rate
and use a significant amount of cpu time) it may be a good
idea to remove C_DIRECT_EXEC altogether.
The ipfw dummynet code is not run from the timer callback. It is run
from a taskqueue. I suspect there is likely a bug somewhere. At the
moment it is not clear to me if there is a bug in the callout subsystem,
that the when the timer is started with 1 tick delay it doesn't kick in
until after 50ms or so at HZ=4000. Or if the dummynet's task is doing a
lot of work for 50ms. I think we need some more information to nail this
one.
--HPS
cheers
luigi
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
