mbox series

[RFC,0/2] CPU non-blocking delay

Message ID 20180831124358eucas1p22a0f8a7d0ae34dfad73b3b9e819366ec~P_LFZr9ro1664316643eucas1p2m@eucas1p2.samsung.com (mailing list archive)
Headers
Series CPU non-blocking delay |

Message

Ilya Maximets Aug. 31, 2018, 12:45 p.m. UTC 
  Sending as RFC because I failed to force meson to
build without deprecation warnings. I tried a lot
of different combinations of 'allow_experimental_apis'
and '-DALLOW_EXPERIMENTAL_APIS' without success.
Any help appreciated.

Ilya Maximets (2):
  eal: add nanosleep based delay function
  drivers/net: use sleep delay by default for intel NICs

 drivers/net/avf/Makefile                      |  1 +
 drivers/net/avf/base/avf_osdep.h              |  4 +-
 drivers/net/e1000/Makefile                    |  1 +
 drivers/net/e1000/base/e1000_osdep.h          |  2 +-
 drivers/net/i40e/base/i40e_osdep.h            |  6 +--
 drivers/net/ifc/base/ifcvf_osdep.h            |  2 +-
 drivers/net/ixgbe/base/ixgbe_osdep.h          |  2 +-
 lib/librte_eal/common/eal_common_timer.c      | 19 +++++++
 .../common/include/generic/rte_cycles.h       | 11 ++++
 lib/librte_eal/rte_eal_version.map            |  1 +
 test/test/autotest_data.py                    |  6 +++
 test/test/meson.build                         |  1 +
 test/test/test_cycles.c                       | 51 ++++++++++++++-----
 13 files changed, 85 insertions(+), 22 deletions(-)

Comments

Bruce Richardson Aug. 31, 2018, 1:01 p.m. UTC | #1 
On Fri, Aug 31, 2018 at 03:45:15PM +0300, Ilya Maximets wrote:
> Sending as RFC because I failed to force meson to
> build without deprecation warnings. I tried a lot
> of different combinations of 'allow_experimental_apis'
> and '-DALLOW_EXPERIMENTAL_APIS' without success.
> Any help appreciated.
> 

I'll try and take a look.

/Bruce
Bruce Richardson Aug. 31, 2018, 1:39 p.m. UTC | #2 
On Fri, Aug 31, 2018 at 03:45:15PM +0300, Ilya Maximets wrote:
> Sending as RFC because I failed to force meson to
> build without deprecation warnings. I tried a lot
> of different combinations of 'allow_experimental_apis'
> and '-DALLOW_EXPERIMENTAL_APIS' without success.
> Any help appreciated.
> 

See patch: http://patches.dpdk.org/patch/44129/

Basically, the experimental_apis setting was not getting passed through and
used by the base code libraries when set at the higher level, since they
were being built individually by the respective base/meson.build files,
rather than by the main driver build loop. Putting in an explicit check for
the value in the base code files should make your life easier here. You
just need to ensure that the "allow_experimental_apis" setting is set
*before* the call to "subdir(base)" e.g. in ixgbe, it's currently after and
needs to be moved by your patchset.

Regards,
/Bruce

PS: I also notice that i40e is using the experimental APIs cflags directly,
rather than the variable, I'll have to fix that in a later patch.
Ilya Maximets Sept. 3, 2018, 2:41 p.m. UTC | #3 
On 31.08.2018 16:39, Bruce Richardson wrote:
> On Fri, Aug 31, 2018 at 03:45:15PM +0300, Ilya Maximets wrote:
>> Sending as RFC because I failed to force meson to
>> build without deprecation warnings. I tried a lot
>> of different combinations of 'allow_experimental_apis'
>> and '-DALLOW_EXPERIMENTAL_APIS' without success.
>> Any help appreciated.
>>
> 
> See patch: http://patches.dpdk.org/patch/44129/
> 
> Basically, the experimental_apis setting was not getting passed through and
> used by the base code libraries when set at the higher level, since they
> were being built individually by the respective base/meson.build files,
> rather than by the main driver build loop. Putting in an explicit check for
> the value in the base code files should make your life easier here. You
> just need to ensure that the "allow_experimental_apis" setting is set
> *before* the call to "subdir(base)" e.g. in ixgbe, it's currently after and
> needs to be moved by your patchset.

Thanks. It works.

Best regards, Ilya Maximets.

> 
> Regards,
> /Bruce
> 
> PS: I also notice that i40e is using the experimental APIs cflags directly,
> rather than the variable, I'll have to fix that in a later patch.
> 
>