2017-01-20 5:38 GMT-08:00 Jan Scheurich <jan.scheur...@web.de>:
>
>>> +static inline void
>>> +emc_probabilistic_insert(struct dp_netdev_pmd_thread *pmd,
>>> + struct emc_cache *cache,
>>> + const struct netdev_flow_key *key,
>>> + struct dp_netdev_flow *flow)
>>> +{
>>> + /* One in every EM_FLOW_INSERT_PROB packets are inserted to reduce
>>> + * thrashing */
>>> + if ((key->hash ^ (uint32_t)pmd->last_cycles) <= EM_FLOW_INSERT_MIN)
>>> {
>>
>> pmd->last_cycles is always 0 when OVS is compiled without DPDK. While
>> we currently
>> don't require high throughput from this code unless DPDK is enabled, I
>> think that
>> depending only on the hash might decrease the coverage of the exact
>> match cache in
>> the unit tests.
>>
>> Have you thought about just using a counter?
>
>
> I think that probabilistic insertion will in any case impact EMC coverage in
> unit test cases. I doubt that there are test cases that trigger the same DP
> flow often enough to have it inserted into EMC with any probability.
>
> If unit test coverage is the issue, we should set the EMC insertion
> probability to 100% when executing unit tests, e.g. by defining
> emc_probabilistic_insert() to unconditionally call emc_insert() when not
> compiling for DPDK.
>
It's not a big deal, since the most important use case we have for
dpif-netdev is with dpdk, but I'd still like the code to behave
similarly on different platforms. How about defining a function that
uses random_uint32 when compiling without DPDK?
For testing it's not that simple, because unit tests can be run with
or without DPDK. It would need to be configurable at runtime.
Perhaps making EM_FLOW_INSERT_PROB configurable at runtime would also
help people that want to experiment with different values, even
though, based on the comments, I guess they wouldn't really see much
difference.
Again, what do you think about simply using counting the packets and
inserting only 1 every EM_FLOW_INSERT_PROB?
Thanks,
Daniele
> Regards, Jan
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
