Re: [dpdk-dev] [PATCH v10 0/9] Add PMD power mgmt

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> 28/10/2020 14:49, Jerin Jacob:
> > On Wed, Oct 28, 2020 at 7:05 PM Liang, Ma <liang.j.ma@intel.com> wrote:
> > >
> > > Hi Thomas,
> > >   I think I addressed all of the questions in relation to V9. I don't think I can solve the issue of a generic API on my own. From the
> Community Call last week Jerin also said that a generic was investigated but that a single solution wasn't feasible.
> >
> > I think, From the architecture point of view, the specific
> > functionally of UMONITOR may not be abstracted.
> > But from the ethdev callback point of view, Can it be abstracted in
> > such a way that packet notification available through
> > checking interrupt status register or ring descriptor location, etc by
> > the driver. Use that callback as a notification mechanism rather
> > than defining a memory-based scheme that UMONITOR expects? or similar
> > thoughts on abstraction.

I think there is probably some sort of misunderstanding.
This API is not about providing acync notification when next packet arrives.
This is about to putting core to sleep till some event (or timeout) happens.
From my perspective the closest analogy: cond_timedwait().
So we need PMD to tell us what will be the address of the condition variable
we should sleep on.  

> I agree with Jerin.
> The ethdev API is the blocking problem.
> First problem: it is not well explained in doxygen.
> Second problem: it is probably not generic enough (if we understand it well)

It is an address to sleep(/wakeup) on, plus expected value.
Honestly, I can't think-up of anything even more generic then that. 
If you guys have something particular in mind - please share.

> 
> > > This API is experimental and other vendor support can be added as needed. If there are any other open issue let me know?
> 
> Being experimental is not an excuse to throw something
> which is not satisfying.
> 
>