Settings "ovs-dpdk" and "ovs-patch" are currently marked with priority
NM_SETTING_PRIORITY_HW_BASE, which makes them "base" settings. This
means that they can be used as connection type, for example via "nmcli
connection add type ovs-dpdk ...".
This is wrong, as both settings can only belong to a connection of
type "ovs-interface". Decrease their priority and make them non-base
settings.
The problem was spotted when trying to add a ovs-patch connection via
nmcli:
# nmcli connection add type ovs-patch ifname p con-name q ovs-patch.peer r controller s port-type ovs-port
Warning: controller='s' doesn't refer to any existing profile.
(process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 1682 (_normalize_ovs_interface_type): should not be reached
(process:4580): nm-WARNING **: 10:15:42.807: connection did not verify after normalization: ??
(process:4580): nm-CRITICAL **: 10:15:42.807: file ../src/libnm-core-impl/nm-connection.c: line 2170 (_connection_normalize): should not be reached
Error: Failed to add 'q' connection: ovs-interface.type: A connection with 'ovs-patch' setting must be of connection.type "ovs-interface" but is "ovs-patch"
Fixes: d0ec501163 ('cli: assert that valid_parts are set for base types')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2178
Introduce a new "prefix-delegation" setting. It contains properties
related to the configuration of downstream interfaces using IPv6
prefix-delegation. The only property at the moment is "subnet-id",
which specifies which prefix to choose when the delegation contains
multiple /64 networks.
This patch add support to IPVLAN interface. IPVLAN is a driver for a
virtual network device that can be used in container environment to
access the host network. IPVLAN exposes a single MAC address to the
external network regardless the number of IPVLAN device created inside
the host network. This means that a user can have multiple IPVLAN
devices in multiple containers and the corresponding switch reads a
single MAC address. IPVLAN driver is useful when the local switch
imposes constraints on the total number of MAC addresses that it can
manage.
This patch add support to HSR/PRP interface. Please notice that PRP
driver is represented as HSR too. They are different drivers but on
kernel they are integrated together.
HSR/PRP is a network protocol standard for Ethernet that provides
seamless failover against failure of any network component. It intends
to be transparent to the application. These protocols are useful for
applications that request high availability and short switchover time
e.g electrical substation or high power inverters.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1791
Support managing the loopback interface through NM as the users want to
set the proper mtu for loopback interface when forwarding the packets.
Additionally, the IP addresses, DNS, route and routing rules are also
allowed to configure for the loopback connection profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=2060905
The file "nm-meta-setting-base-impl.c" is shared by "libnm-core-impl" and
"libnmc-setting". For "libnm-core-impl" it uses a efficient lookup from the
gtype. For "libnmc-setting", that class information is not available, so
it did a linear search. Instead, do a binary search.
Tested:
diff --git a/src/libnm-core-impl/nm-meta-setting-base-impl.c b/src/libnm-core-impl/nm-meta-setting-base-impl.c
index 3434c858391f..62c366d2ca42 100644
--- a/src/libnm-core-impl/nm-meta-setting-base-impl.c
+++ b/src/libnm-core-impl/nm-meta-setting-base-impl.c
@@ -821,6 +821,11 @@ nm_meta_setting_infos_by_gtype(GType gtype)
{
const NMMetaSettingInfo *setting_info;
+#if _NM_META_SETTING_BASE_IMPL_LIBNM
+ return _infos_by_gtype_binary_search(gtype);
+#endif
+ nm_assert_not_reached();
+
#if _NM_META_SETTING_BASE_IMPL_LIBNM
setting_info = _infos_by_gtype_from_class(gtype);
#else
diff --git a/src/libnm-core-impl/tests/test-setting.c b/src/libnm-core-impl/tests/test-setting.c
index 85d549eb766c..65fcafd076c9 100644
--- a/src/libnm-core-impl/tests/test-setting.c
+++ b/src/libnm-core-impl/tests/test-setting.c
@@ -5134,6 +5134,29 @@ main(int argc, char **argv)
{
nmtst_init(&argc, &argv, TRUE);
+ {
+ gs_unref_object NMConnection *con = NULL;
+ guint8 ctr = 0;
+ guint i;
+
+ con = nmtst_create_minimal_connection("test", NULL, NM_SETTING_WIRED_SETTING_NAME, NULL);
+
+ nm_connection_add_setting(con, nm_setting_wired_new());
+
+ nmtst_connection_normalize(con);
+ nmtst_assert_connection_verifies_without_normalization(con);
+
+ for (i = 0; i < 10000000; i++) {
+ ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIRED));
+ ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_CONNECTION));
+ ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_PROXY));
+ ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_WIREGUARD));
+ ctr += GPOINTER_TO_UINT(nm_connection_get_setting(con, NM_TYPE_SETTING_IP4_CONFIG));
+ }
+
+ return !!ctr;
+ }
+
g_test_add_func("/libnm/test_connection_uuid", test_connection_uuid);
g_test_add_func("/libnm/settings/test_nm_meta_setting_types_by_priority",
Results of `make src/libnm-core-impl/tests/test-setting && libtool --mode=execute perf stat -r 5 -B src/libnm-core-impl/tests/test-setting`:
1) previous linear search: 3,182.81 msec
2) bsearch not inlined: 1,611.19 msec
3) bsearch open-coded: 1,214.45 msec
4) bsearch inlined: 1,167.70 msec
5) lookup from class: 1,147.64 msec
1) previous implementation
2) using nm_array_find_bsearch()
3) manually implementing binary search
4) using nm_array_find_bsearch_inline()
5) only available to libnm-core as it uses internal meta data
Note that for "libnm-core-impl" the implementation was already fast (5), and
it didn't change. It only changed to binary search for "libnmc-setting",
which arguably is a less strong use-case.
The file "nm-meta-setting-base-impl.c" is present twice in our source
tree and compiled twice. Once with internal headers of libnm-core and
once with only public headers.
Consequently, there are two implementations for
nm_meta_setting_infos_by_gtype(), one that can benefit from internal
access to the data structure, and the one for libnmc, which cannot.
Refactor the implementations, in the hope to have it clearer.
Have "len" before "elem_size". That is consistent with g_qsort_with_data()
and bsearch(), and is also what I would expect.
Note that the previous commit just renamed the function. If a user
of the new, changed API gets backported to an older branch, we will
get a compilation error and note that the arguments need to be adjusted.
The "nm_utils_" prefix is just too verbose. Drop it.
Also, Posix has a bsearch function. As this function
is similar, rename it.
Note that currently the arguments are provided in differnt
order from bsearch(). That will be partly addressed next.
That is the main reason for the rename. The next commit
will swap the arguments, so do a rename first to get a compilation
error when backporting a patch that uses the changed API.
We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.
So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.
As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).
The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as
Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)
[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
nm_meta_setting_infos is a list of all NMMetaSettingInfo, sorted by name.
Add nm_meta_setting_types_by_priority which provides a mapping with a
different sort order (first by priority). We need that sometimes.
When subclassing a GObject type, the class and object structs
must be available and defined in the header.
For libnm, and in particular for NMSetting classes, we don't want
users to subclass NMSetting. It also doesn't work, because libnm
has internal code that is necessary to hook up the NMSetting class.
You cannot define your own type and make it work together with
libnm.
Having the structs in public headers limits what we can do with them.
For example, we could embed the private data directly in the structures
and avoid the additional indirection.
This is an API break, but for something that most likely nobody cares
about. Or better, nobody should care about. API is not what is
accidentally defined in a header, API was the library provides to
meaningfully use. Subclassing these types is not meaningful and was
only accidentally possible so far.
Only hide the structs for now. More cleanup is possible later. We shall
however aim to keep the padding and struct layout to not also break ABI.
(cherry picked from commit e46d484fae)
