Re: [dpdk-dev] [PATCH v9 1/3] ethdev: add an API to get device configuration info

[Thomas Monjalon <thomas@monjalon.net>]

04/10/2021 13:20, Ferruh Yigit:
> On 9/27/2021 8:56 AM, Thomas Monjalon wrote:
> > 27/09/2021 09:21, Wang, Jie1X:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >>> 26/09/2021 11:20, Jie Wang:
> >>>> This patch adds a new API "rte_eth_dev_conf_info_get()" to help users
> >>>> get device configuration info.
> >>> [...]
> >>>> + * Retrieve the configuration of an Ethernet device.
> >>>> + *
> >>>> + * @param port_id
> >>>> + *   The port identifier of the Ethernet device.
> >>>> + * @param dev_conf_info
> >>>> + *   A pointer to a structure of type *rte_eth_conf* to be filled with
> >>>> + *   the configuration of the Ethernet device.
> >>>> + *   And the memory of the structure should be allocated by the caller.
> >>>> + * @return
> >>>> + *   - (0) if successful.
> >>>> + *   - (-ENODEV) if *port_id* invalid.
> >>>> + *   - (-EINVAL) if bad parameter.
> >>>> + */
> >>>> +__rte_experimental
> >>>> +int rte_eth_dev_conf_info_get(uint16_t port_id,
> >>>> +				struct rte_eth_conf *dev_conf_info);
> >>>
> >>> It does not make sense to me.
> >>> rte_eth_conf is passed by the app to rte_eth_dev_configure.
> >>> Why the app would need to get the same info back?
> >>>
> >>>
> >>
> >> In rte_eth_dev_configure, dev->data->dev_conf copies the info from port->dev_conf, and then the driver updates it. It doesn't same as port->dev_conf.
> >> We need to get the updated device configuration.
> > 
> > OK I see.
> > Please update the commit log to explain this.
> > 
> 
> Also either an application needs to keep copy of the configuration (like testpmd
> does), or won't have any way to know device configuration details.
> And for the apps that keeps the configuration, it has a risk that application
> copy and device copy of the configuration diverged, as Jie mentioned.
> 
> I think it makes sense to have a way to get the configuration from device, small
> applications can rely on it without keeping a copy of a config at all.
> 
> And for testpmd, we have aligned with Xiaoyun to rely on the device
> configuration more, in a way:
> - When to display a config, use device copy as much as possible
> - Use app copy of config to accumulate user config change requests to apply them
> later, sync app config with device config after config applied.

Makes sense, thanks.