iface: return an error when mtu is too big on creation #455

rjarry · 2025-12-11T09:36:30Z

When creating an interface, iface_set_mtu is not called. When the MTU value is larger than gr_config.max_mtu, it causes such spams in the logs:

ERR: GROUT: iface_cp_poll: rte_pktmbuf_alloc No such file or directory
ERR: GROUT: iface_cp_poll: rte_pktmbuf_alloc No such file or directory
ERR: GROUT: iface_cp_poll: rte_pktmbuf_alloc No such file or directory

Move the mtu and promisc configuration after the interface has been stored in the ifaces array. Reset the ifaces array value on error.

coderabbitai

Actionable comments posted: 2

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 260e390 and e44437b.

📒 Files selected for processing (1)

modules/infra/control/iface.c (4 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{c,h}

⚙️ CodeRabbit configuration file

**/*.{c,h}: - gr_vec_*() functions cannot fail. No need to check their return value.

gr_vec_free(x) always sets x = NULL. There is no risk of double free.

ec_node_*() functions consume their ec_node arguments. No leaks on error.

rte_node->ctx is an uint8_t array of size 16, not a pointer.

Never suggest to replace assert() with graceful error checking.

We compile with -std=gnu2x. Unnamed parameters in function definitions are valid.

Files:

modules/infra/control/iface.c

🧠 Learnings (1)

📚 Learning: 2025-11-05T13:55:26.189Z

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 372
File: smoke/cross_vrf_forward_test.sh:18-18
Timestamp: 2025-11-05T13:55:26.189Z
Learning: In the DPDK/grout codebase, VRF interfaces (named gr-vrf<id>) are automatically created when an interface is added to a non-existing VRF using port_add. The VRF creation is handled automatically by the event system in vrf_netlink.c, so no explicit VRF interface creation commands are needed in test scripts.

Applied to files:

modules/infra/control/iface.c

🧬 Code graph analysis (1)

modules/infra/control/iface.c (1)

modules/infra/control/gr_iface.h (1)

iface (16-25)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)

GitHub Check: build-and-tests (gcc-14, address, debug, ubuntu-24.04, -Dfrr=enabled, true)
GitHub Check: build-and-tests (clang-15, none, debugoptimized, ubuntu-22.04, false)
GitHub Check: build-and-tests (gcc-13, none, debugoptimized, ubuntu-24.04, -Dfrr=enabled, false)
GitHub Check: build-and-tests (clang-16, none, debugoptimized, ubuntu-24.04, false)
GitHub Check: build-and-tests (clang-18, none, debugoptimized, ubuntu-24.04, false)
GitHub Check: deb
GitHub Check: rpm

🔇 Additional comments (1)

modules/infra/control/iface.c (1)

148-149: Cleanup logic is correct.

The ifid_valid flag properly gates the ifaces[ifid] cleanup, ensuring the array entry is only cleared when a valid interface ID was assigned. This prevents clearing unassigned slots if failure occurs before interface ID allocation.

modules/infra/control/iface.c

coderabbitai

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

modules/infra/control/ctlplane.c (1)
405-410: Unchecked return value may use uninitialized MAC address.

If iface_get_eth_addr fails (returns negative, e.g., EOPNOTSUPP for interface types without a MAC), mac remains uninitialized and garbage is written to the hardware address via memcpy.
-	iface_get_eth_addr(iface, &mac);
-	memcpy(ifr.ifr_hwaddr.sa_data, mac.addr_bytes, sizeof(mac));
-	if (ioctl(ioctl_sock, SIOCSIFHWADDR, &ifr) < 0) {
-		LOG(ERR, "ioctl(SIOCSIFHWADDR) %s", strerror(errno));
-		goto err;
+	if (iface_get_eth_addr(iface, &mac) == 0) {
+		memcpy(ifr.ifr_hwaddr.sa_data, mac.addr_bytes, sizeof(mac));
+		if (ioctl(ioctl_sock, SIOCSIFHWADDR, &ifr) < 0) {
+			LOG(ERR, "ioctl(SIOCSIFHWADDR) %s", strerror(errno));
+			goto err;
+		}
 	}

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 76169cf and 98d2969.

📒 Files selected for processing (18)

modules/dhcp/control/client.c (1 hunks)
modules/dhcp/control/packet.c (1 hunks)
modules/infra/api/iface.c (2 hunks)
modules/infra/control/bond.c (7 hunks)
modules/infra/control/ctlplane.c (3 hunks)
modules/infra/control/gr_bond.h (1 hunks)
modules/infra/control/gr_iface.h (1 hunks)
modules/infra/control/iface.c (15 hunks)
modules/infra/control/loopback.c (3 hunks)
modules/infra/control/port.c (1 hunks)
modules/infra/control/vlan.c (4 hunks)
modules/infra/datapath/eth_input.c (1 hunks)
modules/infra/datapath/eth_output.c (1 hunks)
modules/ip/control/address.c (1 hunks)
modules/ip/datapath/arp_output_reply.c (1 hunks)
modules/ip/datapath/arp_output_request.c (2 hunks)
modules/ip6/control/address.c (2 hunks)
modules/ip6/control/router_advert.c (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

modules/infra/control/port.c

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{c,h}

⚙️ CodeRabbit configuration file

**/*.{c,h}: - gr_vec_*() functions cannot fail. No need to check their return value.

gr_vec_free(x) always sets x = NULL. There is no risk of double free.

ec_node_*() functions consume their ec_node arguments. No leaks on error.

rte_node->ctx is an uint8_t array of size 16, not a pointer.

Never suggest to replace assert() with graceful error checking.

We compile with -std=gnu2x. Unnamed parameters in function definitions are valid.

Files:

modules/dhcp/control/client.c
modules/dhcp/control/packet.c
modules/ip/datapath/arp_output_request.c
modules/infra/control/gr_bond.h
modules/ip/control/address.c
modules/ip/datapath/arp_output_reply.c
modules/ip6/control/router_advert.c
modules/infra/datapath/eth_output.c
modules/infra/api/iface.c
modules/infra/datapath/eth_input.c
modules/ip6/control/address.c
modules/infra/control/vlan.c
modules/infra/control/gr_iface.h
modules/infra/control/loopback.c
modules/infra/control/ctlplane.c
modules/infra/control/iface.c
modules/infra/control/bond.c

🧠 Learnings (5)

📚 Learning: 2025-11-05T14:28:28.817Z

Learnt from: rjarry
Repo: DPDK/grout PR: 372
File: modules/infra/datapath/loop_input.c:53-56
Timestamp: 2025-11-05T14:28:28.817Z
Learning: In modules/infra/datapath/loop_input.c, the l3_edges array is intentionally indexed using network byte order (rte_be16_t) for EtherType values. Both loopback_input_add_type() registration and loopback_input_process() lookup use network byte order consistently, so no byte order conversion is needed when accessing l3_edges.

Applied to files:

modules/ip/datapath/arp_output_request.c
modules/ip/datapath/arp_output_reply.c
modules/infra/datapath/eth_output.c
modules/infra/datapath/eth_input.c

📚 Learning: 2025-09-25T07:52:17.403Z

Learnt from: rjarry
Repo: DPDK/grout PR: 312
File: frr/rt_grout.c:355-361
Timestamp: 2025-09-25T07:52:17.403Z
Learning: The nexthop_new() function in FRR's zebra codebase cannot fail and return NULL - it will abort() the process if memory allocation fails, so null checks after calling nexthop_new() are unnecessary.

Applied to files:

modules/ip/control/address.c
modules/infra/control/iface.c

📚 Learning: 2025-11-05T13:55:26.189Z

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 372
File: smoke/cross_vrf_forward_test.sh:18-18
Timestamp: 2025-11-05T13:55:26.189Z
Learning: In the DPDK/grout codebase, VRF interfaces (named gr-vrf<id>) are automatically created when an interface is added to a non-existing VRF using port_add. The VRF creation is handled automatically by the event system in vrf_netlink.c, so no explicit VRF interface creation commands are needed in test scripts.

Applied to files:

modules/ip6/control/address.c
modules/infra/control/gr_iface.h
modules/infra/control/loopback.c
modules/infra/control/iface.c

📚 Learning: 2025-09-22T09:21:51.749Z

Learnt from: rjarry
Repo: DPDK/grout PR: 312
File: modules/ip/control/address.c:102-110
Timestamp: 2025-09-22T09:21:51.749Z
Learning: The rib4_insert() function in the IP module takes ownership of the nexthop reference and automatically calls nexthop_decref(nh) on failure paths, so callers don't need to manually decrement the reference count when rib4_insert fails.

Applied to files:

modules/infra/control/iface.c

📚 Learning: 2025-09-22T09:21:51.749Z

Learnt from: rjarry
Repo: DPDK/grout PR: 312
File: modules/ip/control/address.c:102-110
Timestamp: 2025-09-22T09:21:51.749Z
Learning: The rib4_insert() function in modules/ip/control/route.c takes ownership of the nexthop reference by calling nexthop_incref(nh) at the beginning and properly calls nexthop_decref(nh) on any failure paths via the fail: label, so callers don't need to manually decrement the reference count when rib4_insert fails.

Applied to files:

modules/infra/control/iface.c

🧬 Code graph analysis (12)

modules/dhcp/control/client.c (1)

modules/infra/control/gr_iface.h (1)

iface (16-25)

modules/dhcp/control/packet.c (2)

modules/infra/control/iface.c (1)

iface_get_eth_addr (265-277)

modules/infra/control/gr_iface.h (1)

iface (16-25)

modules/ip/control/address.c (2)

modules/infra/control/iface.c (1)

iface_get_eth_addr (265-277)

modules/infra/control/gr_iface.h (1)

iface (16-25)

modules/ip/datapath/arp_output_reply.c (2)

modules/infra/control/iface.c (1)

iface_get_eth_addr (265-277)

modules/infra/control/gr_iface.h (1)

iface (16-25)

modules/ip6/control/router_advert.c (1)

modules/infra/control/iface.c (1)

iface_get_eth_addr (265-277)

modules/infra/datapath/eth_output.c (1)

modules/infra/control/iface.c (1)

iface_get_eth_addr (265-277)

modules/infra/datapath/eth_input.c (1)

modules/infra/control/iface.c (1)

iface_get_eth_addr (265-277)

modules/ip6/control/address.c (2)

modules/infra/control/iface.c (1)

iface_get_eth_addr (265-277)

modules/infra/control/gr_iface.h (1)

iface (16-25)

modules/infra/control/vlan.c (1)

modules/infra/control/iface.c (4)

iface_del_eth_addr (324-336)

iface_from_id (256-263)

iface_get_eth_addr (265-277)

iface_add_eth_addr (310-322)

modules/infra/control/loopback.c (3)

modules/infra/control/iface.c (2)

iface_destroy (399-437)

iface_next (239-254)

modules/infra/control/gr_iface.h (1)

iface (16-25)

modules/infra/control/worker_test.c (1)

iface_next (49-58)

modules/infra/control/iface.c (3)

modules/infra/control/gr_iface.h (1)

iface (16-25)

api/gr_errno.h (1)

errno_set (9-12)

modules/infra/control/nexthop.c (1)

nexthop_iface_cleanup (537-540)

modules/infra/control/bond.c (2)

modules/infra/control/iface.c (4)

iface_add_eth_addr (310-322)

iface_del_eth_addr (324-336)

iface_set_mtu (338-356)

iface_get_eth_addr (265-277)

modules/infra/control/gr_iface.h (1)

iface (16-25)

🔇 Additional comments (22)

modules/dhcp/control/packet.c (1)

116-119: LGTM!

The API migration from ID-based to pointer-based iface_get_eth_addr is correct. The iface pointer is already validated at lines 110-114, and error handling remains intact.

modules/dhcp/control/client.c (1)

43-44: LGTM!

Correct migration to pointer-based API. The iface pointer is validated at lines 39-41, and error handling is preserved.

modules/ip/control/address.c (1)

101-102: LGTM!

The pointer-based API call is correct with proper error handling.

modules/infra/control/gr_bond.h (1)

16-16: LGTM!

Removing const allows bond member operations to use the new mutable interface APIs.

modules/ip/datapath/arp_output_request.c (1)

64-64: LGTM!

The pointer-based API migration is correct. While iface_from_id might return NULL, iface_get_eth_addr handles NULL internally and the error check at line 109 properly routes failures to the ERROR edge.

Also applies to: 108-112

modules/ip6/control/router_advert.c (1)

145-152: LGTM!

The API migration correctly passes the iface pointer directly. Error handling is preserved.

modules/infra/api/iface.c (2)

38-38: LGTM!

Correct usage of pointer-based iface_destroy API in the error path.

60-60: LGTM!

Proper use of the pointer-based iface_destroy API with the already-resolved iface pointer.

modules/ip/datapath/arp_output_reply.c (1)

58-58: LGTM!

The API migration is correct. The iface pointer is validated at lines 43-48.

modules/infra/datapath/eth_output.c (1)

72-75: LGTM!

The migration to pointer-based iface_get_eth_addr is correct, and the error path properly routes to NO_MAC edge on failure.

modules/ip6/control/address.c (2)

213-214: LGTM!

Correct migration to pointer-based API with proper error handling.

395-399: LGTM!

Correct migration with proper conditional check on return value.

modules/infra/control/ctlplane.c (2)

83-84: LGTM!

Correct migration to pointer-based iface_destroy.

117-118: LGTM!

Correct migration to pointer-based iface_destroy.
modules/infra/control/vlan.c (5)
52-52: LGTM!

cur_parent is validated at lines 47-48 before use here.

93-101: LGTM!

iface_get_eth_addr and iface_add_eth_addr return EINVAL if parent is NULL, and error paths propagate correctly.

160-168: LGTM!

iface_add_eth_addr returns EINVAL for NULL parent, error propagates correctly.

170-178: LGTM!

iface_del_eth_addr returns EINVAL for NULL parent, error propagates correctly.

107-120: Verify iface_del_subinterface handles NULL parent.

At line 109, iface_from_id could return NULL if the parent was destroyed before the VLAN. While iface_del_eth_addr handles NULL gracefully at line 114, iface_del_subinterface(parent, iface) at line 117 may not.
#!/bin/bash
# Check if iface_del_subinterface handles NULL first argument
ast-grep --pattern $'void iface_del_subinterface($_, $_) {
  $$$
}'
rg -n -A10 'void iface_del_subinterface'
modules/infra/control/loopback.c (3)

100-102: LGTM!

Correct migration to pointer-based iface_destroy.

131-132: LGTM!

Correct migration to pointer-based iface_destroy.

192-196: LGTM!

Iterator type correctly changed to non-const to allow passing to iface_destroy.

modules/infra/control/iface.c

coderabbitai

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

modules/infra/control/port.c (1)
231-252: Port left stopped if rte_eth_dev_set_mtu fails.

If rte_eth_dev_set_mtu returns an error other than ENOSYS/EOPNOTSUPP, the function exits at line 242 without restarting the port. The interface becomes inoperable until manually reconfigured or destroyed.
 	ret = rte_eth_dev_set_mtu(p->port_id, mtu);
 	switch (ret) {
 	case 0:
 	case -ENOSYS:
 	case -EOPNOTSUPP:
 		break;
 	default:
-		return errno_log(-ret, "rte_eth_dev_set_mtu");
+		errno_log(-ret, "rte_eth_dev_set_mtu");
+		goto restart;
 	}
+restart:
 	if ((ret = rte_eth_dev_start(p->port_id)) < 0)
 		return errno_log(-ret, "rte_eth_dev_start");
 	p->started = true;
+	if (ret < 0)
+		return ret;
 	iface->mtu = mtu;
Alternatively, save the error from rte_eth_dev_set_mtu and return it after restarting the port.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d2758b6 and 003f307.

📒 Files selected for processing (2)

modules/infra/control/iface.c (15 hunks)
modules/infra/control/port.c (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{c,h}

⚙️ CodeRabbit configuration file

**/*.{c,h}: - gr_vec_*() functions cannot fail. No need to check their return value.

gr_vec_free(x) always sets x = NULL. There is no risk of double free.

ec_node_*() functions consume their ec_node arguments. No leaks on error.

rte_node->ctx is an uint8_t array of size 16, not a pointer.

Never suggest to replace assert() with graceful error checking.

We compile with -std=gnu2x. Unnamed parameters in function definitions are valid.

Files:

modules/infra/control/port.c
modules/infra/control/iface.c

🧠 Learnings (5)

📓 Common learnings

Learnt from: rjarry
Repo: DPDK/grout PR: 372
File: modules/infra/datapath/loop_input.c:53-56
Timestamp: 2025-11-05T14:28:28.817Z
Learning: In modules/infra/datapath/loop_input.c, the l3_edges array is intentionally indexed using network byte order (rte_be16_t) for EtherType values. Both loopback_input_add_type() registration and loopback_input_process() lookup use network byte order consistently, so no byte order conversion is needed when accessing l3_edges.

Learnt from: rjarry
Repo: DPDK/grout PR: 408
File: api/gr_net_types.h:78-84
Timestamp: 2025-11-24T12:50:09.337Z
Learning: In api/gr_net_types.h, ip4_addr_t values are stored in network byte order (big-endian). When using a union to cast to a byte array (uint8_t u8[4]), accessing u8[0] correctly reads the first octet (most significant byte) of the IP address on all architectures, because it directly accesses the memory layout rather than performing integer operations. This pattern is valid for checking properties like multicast (first octet in range 224-239).

📚 Learning: 2025-09-22T09:21:51.749Z

Learnt from: rjarry
Repo: DPDK/grout PR: 312
File: modules/ip/control/address.c:102-110
Timestamp: 2025-09-22T09:21:51.749Z
Learning: The rib4_insert() function in the IP module takes ownership of the nexthop reference and automatically calls nexthop_decref(nh) on failure paths, so callers don't need to manually decrement the reference count when rib4_insert fails.

Applied to files:

modules/infra/control/iface.c

📚 Learning: 2025-09-22T09:21:51.749Z

Learnt from: rjarry
Repo: DPDK/grout PR: 312
File: modules/ip/control/address.c:102-110
Timestamp: 2025-09-22T09:21:51.749Z
Learning: The rib4_insert() function in modules/ip/control/route.c takes ownership of the nexthop reference by calling nexthop_incref(nh) at the beginning and properly calls nexthop_decref(nh) on any failure paths via the fail: label, so callers don't need to manually decrement the reference count when rib4_insert fails.

Applied to files:

modules/infra/control/iface.c

📚 Learning: 2025-09-25T07:52:17.403Z

Learnt from: rjarry
Repo: DPDK/grout PR: 312
File: frr/rt_grout.c:355-361
Timestamp: 2025-09-25T07:52:17.403Z
Learning: The nexthop_new() function in FRR's zebra codebase cannot fail and return NULL - it will abort() the process if memory allocation fails, so null checks after calling nexthop_new() are unnecessary.

Applied to files:

modules/infra/control/iface.c

📚 Learning: 2025-11-05T13:55:26.189Z

Learnt from: maxime-leroy
Repo: DPDK/grout PR: 372
File: smoke/cross_vrf_forward_test.sh:18-18
Timestamp: 2025-11-05T13:55:26.189Z
Learning: In the DPDK/grout codebase, VRF interfaces (named gr-vrf<id>) are automatically created when an interface is added to a non-existing VRF using port_add. The VRF creation is handled automatically by the event system in vrf_netlink.c, so no explicit VRF interface creation commands are needed in test scripts.

Applied to files:

modules/infra/control/iface.c

🧬 Code graph analysis (1)

modules/infra/control/iface.c (3)

modules/infra/control/gr_iface.h (1)

iface (16-25)

api/gr_errno.h (1)

errno_set (9-12)

modules/infra/control/nexthop.c (1)

nexthop_iface_cleanup (537-540)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)

GitHub Check: build-and-tests (gcc-13, none, debugoptimized, ubuntu-24.04, -Dfrr=enabled, false)
GitHub Check: build-and-tests (clang-16, none, debugoptimized, ubuntu-24.04, false)
GitHub Check: build-and-tests (clang-15, none, debugoptimized, ubuntu-22.04, false)
GitHub Check: build-and-tests (clang-18, none, debugoptimized, ubuntu-24.04, false)
GitHub Check: build-and-tests (gcc-14, address, debug, ubuntu-24.04, -Dfrr=enabled, true)
GitHub Check: rpm
GitHub Check: deb

🔇 Additional comments (1)

modules/infra/control/iface.c (1)

338-356: MTU normalization and validation logic looks correct.

The MTU handling properly normalizes 0 to 1500 and enforces the valid range 1280..gr_config.max_mtu, returning ERANGE for out-of-bounds values. This addresses the PR objective of preventing invalid MTU values during interface creation.

modules/infra/control/iface.c

The interface manipulation functions were taking interface IDs as uint16_t parameters and internally calling iface_from_id() to retrieve the struct iface pointer. This approach has several drawbacks. First, it adds unnecessary overhead since most callers already have the iface pointer available. Second, it creates redundant error checking as both the caller and the function need to validate the interface. Third, it obscures the API contract by hiding whether the function operates on the interface object or just uses it as a lookup key. Change these functions to accept struct iface pointers directly. Callers that only have an interface ID must now explicitly call iface_from_id() themselves, making the lookup cost visible at the call site. Functions that previously performed double lookups now do a single one. Error handling for NULL pointers is simplified to use errno_set(EINVAL) consistently. Update bond member structures to use non-const pointers since these manipulation functions require mutable access to properly update interface state. Signed-off-by: Robin Jarry <[email protected]> Reviewed-by: Christophe Fontaine <[email protected]>

If any operation fails after the interface object was "initialized", make sure to call iface_destroy() to properly deallocate resources. Signed-off-by: Robin Jarry <[email protected]> Reviewed-by: Christophe Fontaine <[email protected]>

When creating an interface, iface_set_mtu is not called. When the MTU value is larger than gr_config.max_mtu, it causes such spams in the logs: ERR: GROUT: iface_cp_poll: rte_pktmbuf_alloc No such file or directory ERR: GROUT: iface_cp_poll: rte_pktmbuf_alloc No such file or directory ERR: GROUT: iface_cp_poll: rte_pktmbuf_alloc No such file or directory Now that all the internal iface API takes pointers, we can call iface_set_mtu and iface_set_promisc respectively. Signed-off-by: Robin Jarry <[email protected]> Reviewed-by: Christophe Fontaine <[email protected]>

Reject any MTU smaller than 1280 to comply with the IPv6 standard. If MTU is set to 0, force a default 1500 bytes value. Simplify the port_set_mtu callback accordingly. We don't need to read the MTU from the DPDK port if it is 0 anymore. Link: https://datatracker.ietf.org/doc/html/rfc8200#section-5 Signed-off-by: Robin Jarry <[email protected]> Reviewed-by: Christophe Fontaine <[email protected]>

This comment was marked as resolved.

Sign in to view

rjarry force-pushed the mtu-too-big branch 3 times, most recently from 260e390 to e44437b Compare December 11, 2025 10:39

coderabbitai bot reviewed Dec 11, 2025

View reviewed changes

modules/infra/control/iface.c Outdated Show resolved Hide resolved

modules/infra/control/iface.c Outdated Show resolved Hide resolved

rjarry force-pushed the mtu-too-big branch 2 times, most recently from d08e1e0 to 239f27a Compare December 11, 2025 11:13

christophefontaine approved these changes Dec 11, 2025

View reviewed changes

grout-bot force-pushed the mtu-too-big branch from 239f27a to 76169cf Compare December 11, 2025 11:26

rjarry force-pushed the mtu-too-big branch 2 times, most recently from 98d2969 to d2758b6 Compare December 11, 2025 14:16

coderabbitai bot reviewed Dec 11, 2025

View reviewed changes

modules/infra/control/iface.c Outdated Show resolved Hide resolved

rjarry force-pushed the mtu-too-big branch from d2758b6 to 003f307 Compare December 11, 2025 14:33

coderabbitai bot reviewed Dec 11, 2025

View reviewed changes

modules/infra/control/iface.c Outdated Show resolved Hide resolved

rjarry force-pushed the mtu-too-big branch from 003f307 to ad0599d Compare December 11, 2025 14:43

christophefontaine approved these changes Dec 11, 2025

View reviewed changes

rjarry added 4 commits December 11, 2025 16:07

grout-bot force-pushed the mtu-too-big branch from ad0599d to 62e4d52 Compare December 11, 2025 16:07

christophefontaine merged commit 243e6f2 into DPDK:main Dec 11, 2025
6 checks passed

rjarry deleted the mtu-too-big branch December 11, 2025 16:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

iface: return an error when mtu is too big on creation #455

iface: return an error when mtu is too big on creation #455

Uh oh!

rjarry commented Dec 11, 2025 •

edited

Loading

Uh oh!

This comment was marked as resolved.

coderabbitai bot left a comment

Uh oh!

Uh oh!

Uh oh!

coderabbitai bot left a comment

Uh oh!

Uh oh!

coderabbitai bot left a comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

iface: return an error when mtu is too big on creation #455

iface: return an error when mtu is too big on creation #455

Uh oh!

Conversation

rjarry commented Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rjarry commented Dec 11, 2025 •

edited

Loading