Bug 2179339

Summary:	[ERFE] Add support to the kernel datapath for OVS_ACTION_ATTR_LB_OUTPUT.
Product:	Red Hat Enterprise Linux Fast Datapath	Reporter:	Eelco Chaudron <echaudro>
Component:	openvswitch3.1	Assignee:	OVS RFE <ovs-rfe>
Status:	NEW ---	QA Contact:	ovs-qe
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	FDP 23.A	CC:	ctrautma, egarver, i.maximets, jhsiao, ralongi
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.