Thanks very much. Got it. Thanks. Nick
> On Jan 16, 2017, at 12:31 PM, Daniele Di Proietto <[email protected]> wrote: > > 2017-01-12 23:47 GMT-08:00 nickcooper-zhangtonghao <[email protected] > <mailto:[email protected]>>: >> The dp_netdev_process_rxq_port() will use the “cycles_count_start” and >> “cycles_count_end” for counting the cycles. >> But via perf tool, I found that cycles_count_xxx uses a lot of CPU. One >> question to ask: there is one thread to use the >> pmd struct to processing the packets, right? If so, pmd should be thread >> safety and atomic should not be used for >> cycles_count_xxx. > > 'pmd->cycles' is also read by the main thread. > > The idea is that we don't care about being too accurate, but we > shouldn't be totally inconsistent. > > As explained in 'non_atomic_ullong_add()', we're not doing atomic > increments. We're also not using any memory barrier ('relaxed'). > > By using atomic operation we're only asking the compiler to read/write > the 64-bit word in a single operation, to prevent reading the most > significant 32-bits from an old version and the least significant from > a new version. > > This should have no impact on 64-bit architectures (the generated asm > should be the same as the non atomic case), but might have an effect > on 32-bit architectures. > > I suspect that the functions might show up in perf only when the > thread is not processing packets, because we're executing very few > lines of code over and over. > > Does this make sense to you? > > Thanks, > > Daniele
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
