"Bodireddy, Bhanuprakash" <bhanuprakash.bodire...@intel.com> writes:

>>Bhanuprakash Bodireddy <bhanuprakash.bodire...@intel.com> writes:
>>
>>> This will be used by KA framework that needs millisecond granularity.
>>>
>>> Signed-off-by: Bhanuprakash Bodireddy
>>> <bhanuprakash.bodire...@intel.com>
>>> ---
>>
>>Without this patch, builds starting at 3/7 will fail.  That's pretty
>> bad.  Please see
>>my earlier comment about including helpers when they are used.
>
> As mentioned earlier, it was my mistake and will fix this in v2.
>
>>
>>>  lib/util.c | 12 ++++++++++++
>>>  lib/util.h |  1 +
>>>  2 files changed, 13 insertions(+)
>>>
>>> diff --git a/lib/util.c b/lib/util.c
>>> index 1c06ce0..889ebd8 100644
>>> --- a/lib/util.c
>>> +++ b/lib/util.c
>>> @@ -2125,6 +2125,18 @@ xsleep(unsigned int seconds)
>>>      ovsrcu_quiesce_end();
>>>  }
>>>
>>> +void
>>> +xusleep(unsigned int microseconds)
>>> +{
>>> +    ovsrcu_quiesce_start();
>>> +#ifdef _WIN32
>>> +    Sleep(microseconds/1000);
>>> +#else
>>> +    usleep(microseconds);
>>> +#endif
>>> +    ovsrcu_quiesce_end();
>>> +}
>>> +
>>
>>Wow!  This is deceptive.  If I call this with microseconds argument
>> as, say, 999
>>there's a *strong* chance this will NOT sleep for at least that amount of 
>>time.
>>This function needs a different implementation or just keep it non-windows.
>
> This is indeed deceptive :).  
> I did spend some time to understand if there is an equivalent usleep()
> implementation in Windows and came across Queryperformancecounter and
> usermode scheduling in windows.  I would better stick to non-windows
> implementation and allow the WINDOWS experts add their equivalent
> implantation above.

Since DPDK is only for linux/BSD right now, better to not expose this.
Let it be implemented when it's needed.  I'd make it a static inside
the dpdk.c file.  If the functionality is required from the windows
side, it can be re-abstracted.

> - Bhanuprakash.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to