> > I would not say this is expected behavior.
> >
> > It seems that you are executing on a somewhat slower system (tsc clock
> > seems to be 100/us = 0.1 GHz) and that, even with only 5
> lines logged before and after, the logging output is causing so much slow
> down of the PMD that it
On 11.04.2018 20:45, Jan Scheurich wrote:
> Hi Ilya,
>
> I would not say this is expected behavior.
>
> It seems that you are executing on a somewhat slower system (tsc clock seems
> to be 100/us = 0.1 GHz) and that, even with only 5 lines logged before and
> after, the logging output is
Hi Ilya,
I would not say this is expected behavior.
It seems that you are executing on a somewhat slower system (tsc clock seems to
be 100/us = 0.1 GHz) and that, even with only 5 lines logged before and after,
the logging output is causing so much slow down of the PMD that it continues to
> This patch enhances dpif-netdev-perf to detect iterations with suspicious
> statistics according to the following criteria:
>
> - iteration lasts longer than US_THR microseconds (default 250).
> This can be used to capture events where a PMD is blocked or
> interrupted for such a period of
I see following behaviour:
1. Configure low -us (like 100)
2. After that I see many logs about suspicious iterations (expected).
2018-03-27T13:58:27Z|03574|pmd_perf(pmd7)|WARN|Suspicious iteration (Excessive
total cycles): tsc=520415762246435 duration=106 us
Acked-by: Billy O'Mahony
> -Original Message-
> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> Sent: Sunday, March 18, 2018 5:55 PM
> To: d...@openvswitch.org
> Cc: ktray...@redhat.com; Stokes, Ian ;
> i.maxim...@samsung.com; O
This patch enhances dpif-netdev-perf to detect iterations with
suspicious statistics according to the following criteria:
- iteration lasts longer than US_THR microseconds (default 250).
This can be used to capture events where a PMD is blocked or
interrupted for such a period of time that