On 05/10/17 17:06, Ilya Maximets wrote:
This allows to collect packets from more than one RX burst
and send them together with a configurable intervals.
'other_config:tx-flush-interval' can be used to configure
time that a packet can wait in output batch for sending.
dpif-netdev turned to microsecond resolution for time
measuring to ensure desired resolution of 'tx-flush-interval'.
Signed-off-by: Ilya Maximets <[email protected]>
---8<--- ... --->8---
@@ -2999,6 +3012,16 @@ dpif_netdev_set_config(struct dpif *dpif, const struct
smap *other_config)
smap_get_ullong(other_config, "emc-insert-inv-prob",
DEFAULT_EM_FLOW_INSERT_INV_PROB);
uint32_t insert_min, cur_min;
+ uint32_t tx_flush_interval, cur_tx_flush_interval;
+
+ tx_flush_interval = smap_get_int(other_config, "tx-flush-interval",
+ DEFAULT_TX_FLUSH_INTERVAL);
+ atomic_read_relaxed(&dp->tx_flush_interval, &cur_tx_flush_interval);
+ if (tx_flush_interval != cur_tx_flush_interval) {
+ atomic_store_relaxed(&dp->tx_flush_interval, tx_flush_interval);
+ VLOG_INFO("Flushing interval for tx queues set to %"PRIu32" us",
+ tx_flush_interval);
+ }
I was wondering if it will be an issue that the new value configured
might not
be in effect until the previous configured flush timeout has expired.
I wanted to suggest to maybe store the p->last_flush_time rather than
p->flush
time. But looking at it again, with the maximum value being 1 second, it
should
not be a problem...
All looks good to me
Acked-by: Eelco Chaudron <[email protected]>
---8<--- ... --->8---
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
