On Thu, Jun 24, 2021 at 4:35 PM Burakov, Anatoly
wrote:
> Right, so the idea is store the PMD-specific data in the monitor
> condition, and leave it to the callback to interpret it.
>
> The obvious question then is, how many values is enough? Two? Three?
> Four? This option doesn't really solve th
On 24-Jun-21 4:25 PM, Ananyev, Konstantin wrote:
I did a quick prototype for this, and i don't think it is going to work.
Callbacks with just "current value" as argument will be pretty limited
and will only really work for cases where we know what we are expecting.
However, for cases like even
> >> I did a quick prototype for this, and i don't think it is going to
> >> work.
> >>
> >> Callbacks with just "current value" as argument will be pretty limited
> >> and will only really work for cases where we know what we are
> >> expecting.
> >> However, for cas
On 24-Jun-21 3:57 PM, Ananyev, Konstantin wrote:
I did a quick prototype for this, and i don't think it is going to work.
Callbacks with just "current value" as argument will be pretty limited
and will only really work for cases where we know what we are expecting.
However, for cases like eve
> I did a quick prototype for this, and i don't think it is going to work.
>
> Callbacks with just "current value" as argument will be pretty limited
> and will only really work for cases where we know what we are expecting.
> However, for cases like event/dlb or net/mlx5
On 24-Jun-21 10:47 AM, Ananyev, Konstantin wrote:
I did a quick prototype for this, and i don't think it is going to work.
Callbacks with just "current value" as argument will be pretty limited
and will only really work for cases where we know what we are expecting.
However, for cases like
> >>>
> Previously, the semantics of power monitor were such that we were
> checking current value against the expected value, and if they
> matched,
> then the sleep was aborted. This is somewhat inflexible, because it
> only
> allowed u
On 23-Jun-21 2:27 PM, Ananyev, Konstantin wrote:
On 23-Jun-21 12:00 PM, Ananyev, Konstantin wrote:
Previously, the semantics of power monitor were such that we were
checking current value against the expected value, and if they matched,
then the sleep was aborted. This is somewhat inflexib
> On 23-Jun-21 12:00 PM, Ananyev, Konstantin wrote:
> >
> >
> >> Previously, the semantics of power monitor were such that we were
> >> checking current value against the expected value, and if they matched,
> >> then the sleep was aborted. This is somewhat inflexible, because it
On 23-Jun-21 12:00 PM, Ananyev, Konstantin wrote:
Previously, the semantics of power monitor were such that we were
checking current value against the expected value, and if they matched,
then the sleep was aborted. This is somewhat inflexible, because it only
allowed us to check for a specif
> >>>
> Previously, the semantics of power monitor were such that we were
> checking current value against the expected value, and if they matched,
> then the sleep was aborted. This is somewhat inflexible, because it only
> allowed us to check for a specific value.
>
> >>
On 23-Jun-21 10:55 AM, Ananyev, Konstantin wrote:
-Original Message-
From: Burakov, Anatoly
Sent: Wednesday, June 23, 2021 10:43 AM
To: Ananyev, Konstantin ; dev@dpdk.org; Richardson,
Bruce
Cc: Loftus, Ciara ; Hunt, David
Subject: Re: [PATCH v1 1/7] power_intrinsics: allow monitor
> -Original Message-
> From: Burakov, Anatoly
> Sent: Wednesday, June 23, 2021 10:43 AM
> To: Ananyev, Konstantin ; dev@dpdk.org;
> Richardson, Bruce
> Cc: Loftus, Ciara ; Hunt, David
> Subject: Re: [PATCH v1 1/7] power_intrinsics: allow monitor checks inversion
>
> On 21-Jun-21 1:56
On 21-Jun-21 1:56 PM, Ananyev, Konstantin wrote:
Hi Anatoly,
Previously, the semantics of power monitor were such that we were
checking current value against the expected value, and if they matched,
then the sleep was aborted. This is somewhat inflexible, because it only
allowed us to check fo
Hi Anatoly,
> Previously, the semantics of power monitor were such that we were
> checking current value against the expected value, and if they matched,
> then the sleep was aborted. This is somewhat inflexible, because it only
> allowed us to check for a specific value.
>
> This commit adds a
Previously, the semantics of power monitor were such that we were
checking current value against the expected value, and if they matched,
then the sleep was aborted. This is somewhat inflexible, because it only
allowed us to check for a specific value.
This commit adds an option to reverse the che
16 matches
Mail list logo
