I’m using software handling to create connection tracking entries based on packets that are steered into the RSS pipeline. The goal is to track flows and maintain packet counters for each connection.
However, I’ve run into a limitation:
Packet(s) that are sent to software handling (via RSS) and used to create the connection tracking entry are not included in the counters for that connection.
As a result, the first packet(s) that trigger the flow creation are effectively “missing” from the tracked statistics.
I’m trying to understand if there is a supported way to address this. Specifically:
Packet Recirculation:
Is there any mechanism in DOCA / the underlying pipeline to recirculate packets that were handled in software (RSS) back into the hardware pipeline, so they can be processed again and counted as part of the flow?
Counter Initialization:
Alternatively, is it possible to initialize or manually adjust the connection tracking counters at the moment the entry is created, to account for the packet(s) that triggered the flow?
Best Practices:
Is there a recommended pattern for ensuring accurate packet/byte counters when flows are first detected via RSS/software handling?
Any insights, references, or examples would be greatly appreciated.
When the first packets of a flow are steered to RSS and handled in software, they never pass through the CT entry, so they are not included in that entry’s hardware counters. Only packets that match an already-installed CT entry are counted.
1/ Recirculation:
There is no supported way in DOCA/CT to take a packet that already went to RSS and recirculate that same packet back into the CT pipeline just to have it counted.
2/ Counter initialization:
CT counters are hardware-owned; the API lets you enable and read them, but not preset or adjust per-flow counters at creation time. They always start from zero when the entry is created.
3/ Best practice:
Either (a) treat CT counters as “since offload” and maintain your own software counters for the initial RSS packets (then report SW+HW totals), or (b) if you need counting from the very first packet, avoid the SW-first path and let CT handle flow creation directly (e.g., allocate-on-miss/autonomous mode).
For more details with how, please open a support case.
Thanks for the clarification — that matches my observations.
However, regarding point (3b): the DOCA 3.0.0 release notes state that CT autonomous mode is no longer supported and cannot be configured. So it seems that the suggested “allocate-on-miss/autonomous” path is not actually available in current DOCA versions.
Since DOCA_FLOW_CT_ENTRY_FLAGS_ALLOC_ON_MISS only applies during doca_flow_ct_entry_prepare() (i.e., after the packet already went through RSS), I don’t see a way to create the CT entry and count the first packet purely in hardware.
Can you confirm whether there is any supported way in DOCA ≥3.0 to achieve true allocate-on-miss behavior in the CT pipeline, or if the intended approach is to combine software counting for the first packet with hardware counters for the rest?