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.
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.
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
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
