30/10/2020 12:58, McDaniel, Timothy: > From: McDaniel, Timothy > > From: Thomas Monjalon <tho...@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.
