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
As far as I know Ciara did some quick tests with a counter-based
implementation and it performed 5% worse for 1K and 4K flows than then
current patch. Perhaps we could find the reason for that and fix it, but
I also feel uncomfortable with deterministic insertion of every Nth
flow. This could lead to very strange lock-step phenomena with typical
artificial test work loads, which often generate flows round-robin. I
would rather use a random function, as you suggest, or count "cycles"
differently when compiling without DPDK.
I agree to making the parameter EM_FLOW_INSERT_PROB configurable for
unit test or other purposes. Should it be a new option in the
OpenvSwitch table in OVSDB or rather a run-time parameter to be changed
with ovs-appctl?
Jan
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
