@@ -270,3 +270,22 @@ replies are processed concurrently, it's possible one of them will
270270update the flow-open information and emit a flow opening message, but
271271another reply closing the flow without thinking it's ever been opened,
272272thus not sending a flow closing message.
273+
274+ ### Reporting global counters
275+ While the global counters use per-CPU maps, and are therefore safe to
276+ concurrently update in the BPF programs, there is no synchronization
277+ between the BPF programs updating these stats and the user space
278+ fetching them. It is therefore possible that the user space reports
279+ these counters in an inconsistent state, i.e. a BPF program may only
280+ have updated a subset of all the counters it will update by the time
281+ the user space process fetches the map. For example, a BPF program
282+ could have updated the packet count but not the byte count when user
283+ space reports the stats. In practice these errors should be very
284+ small, and any updates missed in one report will be included in the
285+ next, i.e. it has eventual consistency.
286+
287+ This problem could be avoided by using two instances of the maps and
288+ swapping between them (as done by the aggregation stats), however such
289+ a solution is a fair bit more complex, and has slightly more overhead
290+ (needs to perform an initial map lookup to determine which instance of
291+ a map it should update).
0 commit comments