RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1705732 - RFE: nftables: speed up rule listing when only a single table is requested
Summary: RFE: nftables: speed up rule listing when only a single table is requested
Keywords:
Status: CLOSED ERRATA
Alias: None
Deadline: 2022-08-01
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: nftables
Version: 9.0
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: 9.1
Assignee: Phil Sutter
QA Contact: Tomas Dolezal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-02 20:19 UTC by Florian Westphal
Modified: 2022-11-15 13:19 UTC (History)
4 users (show)

Fixed In Version: nftables-1.0.4-1.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 11:22:16 UTC
Type: Enhancement
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2022:8381 0 None None None 2022-11-15 11:22:20 UTC

Description Florian Westphal 2019-05-02 20:19:10 UTC 
Description of problem:
 
a command like "nft list table foo"

might take several seconds, even if this table doesn't contain
a lot of rules and only small sets.

This is because nft populates its cache on startup by dumping entire ruleset,
so every table is processed even if it won't be used.

nft could instead only query the kernel for the requested table.

The caveat is that the command line might read:

nft "list table foo;list table bar"

so its not enough to just restrict fetch to first table it sees.

We also might have a mix of unrelated commands/operations
on different objects in different tables.

One way to fix this would be to maintain cache per table, and
populate it on demand only. This would also need proper invalidation
when tables get altered in mean time.

How reproducible: 100%.

Steps to Reproduce:
1. add new empty table
2. observe speed of "nft list table newtable"
3. add another new table containing e.g.a large set  (e.g. 200k entries)

Actual results:

"nft list table newtable" takes noticably longer to complete

Expected results:

"nft list table newtable" should not take longer to complete
Comment 5 RHEL Program Management 2021-02-01 07:40:40 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 6 Phil Sutter 2021-02-01 14:00:40 UTC 
Maybe implicitly fixed by a future rebase, but worth keeping this in place to have it tested for.
Comment 9 RHEL Program Management 2021-08-01 07:27:05 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 10 Phil Sutter 2021-08-30 13:48:35 UTC 
Still relevant. Also, a quick test with current upstream nftables shows that adding chains to one table slows down listing of another table.
Comment 12 Phil Sutter 2021-12-22 13:58:25 UTC 
Support for filtering data on kernel side has been completed recently in upstream nftables. There are ~40 commits that went into src/cache.c in between those commits and RHEL8. Given that this is an RFE and there's no explicit customer interest, I hereby postpone to RHEL9.
Comment 15 RHEL Program Management 2022-03-02 07:27:21 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 16 Phil Sutter 2022-03-02 17:19:42 UTC 
Still relevant.
Comment 18 Phil Sutter 2022-06-09 16:25:38 UTC 
Likely fixed implicitly by package rebase (bug 1917398), mark as TestOnly?
Comment 20 Phil Sutter 2022-06-16 10:51:33 UTC 
Here's a simple test:

| #!/bin/bash
| 
| {
| 	cat <<EOF
| flush ruleset
| table empty_table {
| }
| table full_table {
| 	chain c {
| EOF
| 	for ((i = 0; i < 50000; i++)); do
| 		echo "iifname eth0 tcp dport 22 counter accept"
| 	done
| 	cat <<EOF
| 	}
| }
| EOF
| } | nft -f -
| 
| TIMEFORMAT='%R'
| time nft list table full_table >/dev/null
| time nft list table empty_table >/dev/null

The second value printed must be significantly lower than the first one.
Comment 27 errata-xmlrpc 2022-11-15 11:22:16 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nftables bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8381
Note You need to log in before you can comment on or make changes to this bug.