RE: [RFC PATCH 1/3] ethdev: add set link state on close API

["Loftus, Ciara" <ciara.loftus@intel.com>]

> 
> Hi Ciara,
> 
> On Fri, 29 Aug 2025, Ciara Loftus wrote:
> 
> > Allow the user to configure the state a link should be in after
> > the device has been stopped/closed. Make this configurable
> > through the new experimental rte_eth_dev_set_link_state_on_close
> > API. Three states are allowed:
> > 1. down: bring (or keep) the link down
> > 2. up: bring (or keep) the link up
> > 3. initial: restore the link to the state it was in when the device was
> > started.
> >
> 
> Perhaps it pays to name it 'status' instead of 'state', as the latter is not
> confined to just 'up/down' but also includes the speed, technology, FEC, etc.

Sure, I think this would be a logical change.

> 
> As for the three cases:
> 
> (3)
> When the driver gets probed, it may discover the link being in some state that
> the previous driver left us, (A). Then if the user does not invoke any APIs to
> tweak the link settings and proceeds straight to 'rte_eth_dev_start', the link
> will be in some best-effort state (B). Otherwise it will be in other state, (C).
> 
> Which one is implied by 'when the device was started'?

I think what we want is (A) - the state the previous driver left us in. I will
look to improve the descriptions if there are further revisions.

> 
> (2)
> Does 'keep' describe the link being up prior to 'close'? If so, then if the
> link is not 'up' prior to 'close', this commands to bring it up, which may
> not be possible if the link partner is gone or the cable is unplugged.

Yes, I guess this is conditional on external factors such as link partner etc.
The documentation can be changed to reflect this. "Try" to bring the
link up.

> 
> (1)
> This is OK. If the driver is capable to force link down, in electrical idle,
> it will do that. If it can't do this, the whole API won't be supported.
> 
> Thank you.

Thank you for your feedback.

Ciara