Thank you!
Small question, though: what do the n_offload_{packets,bytes} fields
represent in the output of "bridge/dump-flows", if not the offload stats
for traffic associated with a given OpenFlow rule? I understand it might
be implemented using datapath flows under the hood, but that shouldn't
matter for my purposes as long as the numbers mean what I expect them to.
On 2/10/23 01:15, Ilya Maximets wrote:
On 2/7/23 15:25, Viacheslav Galaktionov via discuss wrote:
Hi!
I'm trying to figure out if my OvS flows are actually offloaded to TC or DPDK.
To simplify flow management, the test application uses cookies to assign unique
IDs to flows.
As I understand, there are two ways to dump flows from OvS:
1. Use "ovs-ofctl dump-flows", which doesn't return offload stats.
2. Use "ovs-appctl bridge/dump-flows", which doesn't return the cookies.
ovs-ofctl is supposed to work with any OpenFlow switch, and offload stats are
not part of the OpenFlow protocol, so its behaviour is perfectly understandable.
Both methods above are dumping OpenFlow rules and OVS doesn't actually
offload OpenFlow rules themselves. OVS creates simpler datapath flows
while passing a packet through OpenFlow tables. This simple datapath
flow it sends to the datapath inclusing possibility of offloading of
that datapath flow.
So, you won't be able to get offload stats from OpenFlow rules, so neither
of the commands above are suitable for you.
You can dump datapath flows instead with 'ovs-appctl dpctl/dump-flows'.
By using '-m' option you can get additional flags like 'dp_layer'
and 'offloaded:[yes|no|partial]' for each datapath flow.
However, ovs-appctl is an OvS-specific tool and I don't see any reason why it
would omit this flow-identifying information, especially since it doesn't seem
to provide any alternative. I've done some quick testing and this patch appears
to give me what I need:
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 3a527683c..bdf1e7467 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -4803,6 +4803,9 @@ flow_stats_ds(struct ofproto *ofproto, struct rule *rule,
struct ds *results,
if (rule->table_id != 0) {
ds_put_format(results, "table_id=%"PRIu8", ", rule->table_id);
}
+ if (rule->flow_cookie != 0) {
+ ds_put_format(results, "cookie=0x%llx, ", ntohll(rule->flow_cookie));
+ }
ds_put_format(results, "duration=%llds, ", (time_msec() - created) /
1000);
ds_put_format(results, "n_packets=%"PRIu64", ", stats.n_packets);
ds_put_format(results, "n_bytes=%"PRIu64", ", stats.n_bytes);
Am I missing something or am I just the first to need this functionality? Maybe
there's some solution to my problem already and I just don't see it.
Not printing out the cookie value might be just an oversight, as the
"bridge/dump-flows" command is rarely used. It's mostly for dumping
hidden internal OF rules while debugging.
Feel free to submit above change as a formal patch. I'd change the
llx to PRIx64 though.
Best regards, Ilya Maximets.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
