On 2/10/23 16:40, Ilya Maximets wrote:
On 2/10/23 10:14, Viacheslav Galaktionov wrote:
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.
Hmm, you're right. I missed that part.
Stats from datapath flows are aggregated into stats for OpenFlow rules
that contributed into creation of these datapath flows. In this case
n_offload_{packets,bytes} are counting stats from offloaded datapath
flows separately. So, yes, these might be what you need.
Sorry, I'm not normally using this appctl command, so I forgot about this
functionality being implemented. :)
Dumping datapath flows is typically more useful for troubleshooting,
but if you only need statistics, then the 'bridge/dump-flows' should
be sufficient.
Glad to hear this, thank you!
By the way, I've noticed another small discrepancy in how ovs-ofctl and
ovs-appctl dump bridge flows: they use different field names for table
IDs: the former uses "table", while the latter uses "table_id". Do you
think I'd break anything if I patched ovs-appctl to use "table" as well?
Note though that there are some tricky considerations regarding what is
considered 'offloaded' and what is not. For example, with TC, these stats
will count packets matching chains which are in_hw. They will not count
flows installed in TC software datapath, but not in HW, AFAICT.
For DPDK, it will count both fully and partially offloaded flows, even
though actions are executed in software for partially offloaded ones.
Yes, this is an interesting point, thanks. I wonder if it'd be possible
to somehow differentiate between SW and HW offloads, but I suppose the
current behaviour suits my goals well enough.
Best regards, Ilya Maximets.
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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
