[Zeek] Input framework

[Nabil Memon]

Thanks a lot for the thorough explanation.
I really appreciate it.

>From the above explanation, it means that, bro is expecting to be
continued soon after the suspend call to tackle subtle race cases as you
mentioned and there's no rest in between(suspend & continue) which can
stabilize the CPU load(basically it polls for it to be continued again). I
hope it cleared my understanding of how suspend/continue_processing() calls
works.

My use case is I want bro not to process any packets from any source(netmap
pipe or libpcap) until I somehow sends a signal for bro to be continued.
The use case is achieved even now but at a higher cost of CPU being loaded.

>> if you want to make a GitHub issue for that enhancement (also may help
if you provide more explanation of your use-case and the importance of this
to it).
Okay...

Thanks a lot again !!

Regards,
Nabil

On Fri, May 29, 2020 at 10:12 PM Jon Siwek <jsiwek at corelight.com> wrote:

> On Thu, May 28, 2020 at 9:55 PM Nabil Memon <nabilmemon.ec at gmail.com>
> wrote:
>
> > I see bro utilizing 100% CPU when in suspended state. And normal
> percentage CPU(roughly 15-20%) usage when in continued state.
> >
> > Why bro is taking up so much CPU when in suspended state?
>
> From a historical explanation: I don't know, but maybe because it
> wasn't meant for general usage or only for some niche use-cases where
> some short-term high CPU usage was acceptable (the main use-case I
> know is currently in Zeek's test suite to cause determinism in some
> input/IPC tests that otherwise have subtle races).
>
> From a technical explanation: likely it's because the suspend/continue
> functions don't remove the PktSrc file descriptor from the IO/polling
> loop so it's always considered "ready" but also never processes
> anything to drive it forward out of that "ready" state due to being
> "suspended".
>
> The technicalities of suspend/continue performing an
> unregister/register the PktSrc FD are changeable if you want to make a
> GitHub issue for that enhancement (also may help if you provide more
> explanation of your use-case and the importance of this to it).
> Though might not expect any changes related to this happening until
> Zeek 3.2 or later -- 3.0.x has a different IO loop that's trickier to
> change, 3.1.x is a bit easier to change, but this isn't a clear-cut
> "regression" that suits a patch release, and 2.6.x or before are no
> longer supported.
>
> - Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/zeek/attachments/20200531/4a9bb235/attachment.html