Bug 2179339 - [ERFE] Add support to the kernel datapath for OVS_ACTION_ATTR_LB_OUTPUT.
Summary: [ERFE] Add support to the kernel datapath for OVS_ACTION_ATTR_LB_OUTPUT.
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux Fast Datapath
Classification: Red Hat
Component: openvswitch3.1
Version: FDP 23.A
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: ---
Assignee: OVS RFE
QA Contact: ovs-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-17 13:05 UTC by Eelco Chaudron
Modified: 2023-06-30 12:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FD-2750 0 None None None 2023-03-17 13:09:04 UTC

Description Eelco Chaudron 2023-03-17 13:05:57 UTC
Currently, the OVS_ACTION_ATTR_DROP and OVS_ACTION_ATTR_LB_OUTPUT actions are only supported by userspace. It would be nice to have support for both in the kernel.

OVS_ACTION_ATTR_DROP-related statistics can then be retrieved from the kernel module which helps troubleshoot translation issues.

OVS_ACTION_ATTR_LB_OUTPUT will avoid additional recirculation in the kernel module.

Comment 1 Eric Garver 2023-06-22 19:49:13 UTC
> OVS_ACTION_ATTR_DROP-related statistics can then be retrieved from the kernel module which helps troubleshoot translation issues.

Does this mean adding kernel counters for all the xlate_error enum values?

Or is the idea to use the flow statistics and correlate to the drop reason (xlate_error)? OVS_ACTION_ATTR_DROP has a uint32 value for xlate_error.

In either case, making "ovs-appctl coverage/read-counter drop_action_of_pipeline", etc. work seems problematic.
Alternatively, "ovs-appctl dpif/dump-flows" could show "drop(<xlate_error>)" instead of just "drop".

Comment 2 Eelco Chaudron 2023-06-23 10:23:50 UTC
I think coverage counters will not work for this, I guess another dpctl/xxx specific command would do the job. However, your suggestion of changing the flow dump would work also, i.e. show the drop reason if it's not 0.

It might need some investigation this would continue to work with TC and rte_flow offload.

I've added Ilya to need info, as adding these additional actions where his idea.

Comment 3 Ilya Maximets 2023-06-23 11:07:11 UTC
Yeah, the coverage counters will not really work for a kernel datapath.
There are 3 things that can be implemented here:

1. The main idea behind implementing OVS_ACTION_ATTR_DROP was to define
   subsystem-specific drop reasons for OVS in the kernel and use the
   skb_drop_reason() with a specific reason provided from the userspace.

   With that we should be able to get some statistics by capturing trace
   events from the kernel.

2. Additionally, we could collect per-cpu stats per drop reason in the
   kernel and return them as part of OVS_DP_CMD_GET.  Then, these can be
   printed out as part of the dpif/show command or similar.

3. The update for the dpctl/dump-flows output format is a bit orthogonal
   to that, but can be done as well.

Comment 4 Eric Garver 2023-06-30 12:49:35 UTC
Splitting this bug. THIS bug will to be about OVS_ACTION_ATTR_LB_OUTPUT and we will use bug 2076506 for OVS_ACTION_ATTR_DROP.


Note You need to log in before you can comment on or make changes to this bug.