Flow Basic Log Elements: type ATOMIC and type ORDERED

You may notice entries similar to the following in flow basic logs:

== 2017-10-04 11:18:02.971 +0000 ==
Packet received at ingress stage, tag 0, type ORDERED

== 2017-10-04 11:18:02.971 +0000 ==
Packet received at slowpath stage, tag 3053211477, type ATOMIC

== 2017-10-04 11:18:02.971 +0000 ==
Packet received at fastpath stage, tag 16624, type ATOMIC

 What do ATOMIC and ORDERED mean? 

These terms refer to the type of work queue from which the CPU core picked up the associated packet-processing task.

Atomic queues of work must be executed by a single CPU core. Orderable queues of work may be distributed among multiple CPU cores. (The root/etymological meaning of 'atomic' is indivisible (or more literally, non-cuttable).

You may already know from the the article Getting Started: Flow Basic that each dataplane CPU core that processes packets that match the capture filter will generate its own flow log, named pan_task_X.log, where X is the core number. The exact number of files generated by flow-basic debug logging will depend on the type and the number of sessions traced.

Identifying the type of work queue associated with the task will likely not provide you with actionable information for troubleshooting. What it does tell you is that certain discrete sequences of packet-processing tasks can be picked up by the first available CPU core. (New packet? Who's available? There you go! Take the next one in order.).

For some sequences of tasks, it is more efficient for the same CPU core that started the job to finish it — that specific work is 'atomic,' meaning indivisible. It cannot be 'cut up' and distributed across multiple cores.