[dpdk-dev] [PATCH v5 00/23] Add DLB2 PMD

Thomas Monjalon thomas at monjalon.net
Fri Oct 30 14:15:13 CET 2020


30/10/2020 12:58, McDaniel, Timothy:
> From: McDaniel, Timothy
> > From: Thomas Monjalon <thomas at monjalon.net>
> > > 30/10/2020 10:43, Timothy McDaniel:
> > > > - note that the code still uses its private byte-encoded versions of
> > > >   umonitor/umwait, rather than the new functions in the power
> > > >   patch that are built on top of those intrinsics. This is intentional.
> > >
> > > Why? Now these intrinsics are available in the main branch.
> > > We should avoid duplicating such code.
> > >
> > >
> > 
> > I had asked that the low level intrinsics (UMWAIT/UMONITOR) be split out so
> > that DLB/DLB2 could use them instead of its own private byte-encoded versions,
> > but instead we have these wrappers that call the low level intrinsics. Those
> > wrappers
> > introduce additional overhead that is not required for DLB/DLB2. I have a
> > meeting with Ma Liang on Monday to discuss.
> 
> I thought the ask of DLB was to just substitute the low level umwait/umonitor byte
> encoded instructions DLB has defined privately with similar byte-encoded instructions defined in the power
> patch. The power patch does not directly expose those, which is why I did not update DLB/DLB2.
> The power patch does have the advantage of centralizing the race avoidance
> logic, which is a good thing for any PMD that wishes to take advantage of umwait/umonitor.

So you mean the overhead is a good thing?

> Sorry for the confusion. I just misunderstood what was being asked of DLB in regard to switching over..  That being said, 
> I am willing to convert DLB/DLB2 to use  rte_power_monitor(...) in a future patch-set.

Why not now?

Indeed there is a confusion and it looks like a lot of novlang
to exit from the situation.
We'll wait a clear decision with facts.




More information about the dev mailing list