On 11-May-2021 11:39 AM, Anatoly Burakov wrote: > On 11-May-21 4:31 PM, Anatoly Burakov 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 specific value. > > > > We can reverse the check, and instead have monitor sleep to be aborted > > if the expected value *doesn't* match what's in memory. This allows us > > to both implement all currently implemented driver code, as well as > > support more use cases which don't easily map to previous semantics > > (such as waiting on writes to AF_XDP counter value). > > > > This commit also adjusts all current driver implementations to match the > > new semantics. > > > > Signed-off-by: Anatoly Burakov <anatoly.bura...@intel.com> > > --- > > <snip> > > > diff --git a/drivers/net/mlx5/mlx5_rx.c b/drivers/net/mlx5/mlx5_rx.c > > index 6cd71a44eb..3cbbe5bf59 100644 > > --- a/drivers/net/mlx5/mlx5_rx.c > > +++ b/drivers/net/mlx5/mlx5_rx.c > > @@ -282,7 +282,7 @@ int mlx5_get_monitor_addr(void *rx_queue, struct > rte_power_monitor_cond *pmc) > > return -rte_errno; > > } > > pmc->addr = &cqe->op_own; > > - pmc->val = !!idx; > > + pmc->val = !idx; > > pmc->mask = MLX5_CQE_OWNER_MASK; > > pmc->size = sizeof(uint8_t); > > return 0; > > Both previous and current code seem suspicious to me, as no attention is > paid to endianness of the code. I would appreciate if mlx5 maintainers > chimed in here :)
It is hard to mess up with endianness when you only have 1 byte :)
