On Fri, 2 Oct 2026 21:43:35 +0200
Roman Khromenok <[email protected]> wrote:
> Starting a port always brings its link up, so the link partner sees
> the port as soon as the application starts it. An application that
> enables ports only after its own configuration is applied, such as
> a firewall or a switch, cannot keep a disabled port dark: it can only
> bring the link down right after rte_eth_dev_start(), and the link
> partner may still see the link flap.
>
> The ice driver already has the link_state_on_close device argument to
> choose the link state when the port is stopped. This series adds its
> counterpart, link_state_on_start, to the ice, i40e and ixgbe drivers:
>
> -a <pci>,link_state_on_start=down
NAK.
DPDK devices should not be like snowflakes, everyone unique.
When I see patches like this I think one or more of the following:
- a user does not understand how DPDK devices work and does not
want to change their application
- developer refuses to say no to the user.
- DPDK devices semantics are poorly documented.
- DPDK devices do not implement the link states in RFC2863 but should.
RFC 2863 separates ifAdminStatus from ifOperStatus; ethdev should as well.
If you want something done better it must done at ethdev layer
and you must coordinate across all existing devices.
No more specials.
Take user input as problem description, not as directive on how
to solve it.
The link_state_on_close argument in ice is not a precedent. It was
a workaround for hotplug problems and should not have been a devarg
either. Adding a matching on_start option to three drivers repeats
the mistake. I should have objected stronger then.
