Bug 2099689 - [RFE] Investigate possible optimization of metadata restoration actions
Summary: [RFE] Investigate possible optimization of metadata restoration actions
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux Fast Datapath
Classification: Red Hat
Component: OVN
Version: FDP 22.E
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Numan Siddique
QA Contact: Jianlin Shi
URL:
Whiteboard:
Depends On:
Blocks: 2172625
TreeView+ depends on / blocked
 
Reported: 2022-06-21 13:32 UTC by Ilya Maximets
Modified: 2023-07-13 07:25 UTC (History)
6 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-2040 0 None None None 2022-06-21 13:40:52 UTC

Description Ilya Maximets 2022-06-21 13:32:32 UTC
OVN pipeline consists of building blocks, a.k.a. OpenFlow tables.
Flows in some tables are written in a following way:

  match,actions=<save metadata>,<change metadata>,do something,<restore metadata>

This is done this way to be sure that if the flow from some other
table resubmits the packet to this one, after the resubmit the
metadata will stay the same as it was before.

However, if the resubmit to such a table ends up being the last
action, the actual <restore metadata> part is not really necessary
and can be omitted in the OpenFlow rule.

For example, table 64 contains several flows with the same action
list like this:

  actions=push:NXM_OF_IN_PORT[],load:0xffff->NXM_OF_IN_PORT[],resubmit(,65),pop:NXM_OF_IN_PORT[]

It's likely that resubmit to table 64 was the last action in
previous tables all the way up in the OpenFlow piepline.
In this case restoration of the input port value is not really
necessary.

Why it is important?

In case of table 64 actions, the resubmit to table 65 will likely
be the output to the br-ex bridge via the patch port.  Since the
resubmit(,65) is not the last action, OVS will emit a clone()
action while processing flows in the br-ex, if there are some
irreversible actions there.  So, the clone() will be emitted even
if the patch port processing is, in fact, the last meaningful
packet manipulation.  The clone() itself prevents the hardware
offloading, so it would be better if the input port metadata
restoration wasn't there in the first place allowing the HW offload
to happen.

This BZ is to investigate the possibility of not generating such
seemingly pointless metadata restoration actions on the OVN side.

The issue can be worked around on the OVS side, so if there is
no easy and safe way to fix it on OVN side, the OVS solution
should be preferred instead.


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