> > 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
