[dpdk-dev] [PATCH v5 2/4] net/ixgbe: add support of reset

Dai, Wei wei.dai at intel.com
Mon Jul 10 12:19:34 CEST 2017


Thanks, Thomas
I have just sent out my v6 patch set which includes more details to explain why/what/when.

-----Original Message-----
From: Thomas Monjalon [mailto:thomas at monjalon.net] 
Sent: Friday, July 7, 2017 4:36 PM
To: Dai, Wei <wei.dai at intel.com>; Yigit, Ferruh <ferruh.yigit at intel.com>
Cc: dev at dpdk.org; Lu, Wenzhuo <wenzhuo.lu at intel.com>; Ananyev, Konstantin <konstantin.ananyev at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>; Zhang, Helin <helin.zhang at intel.com>; Peng, Yuan <yuan.peng at intel.com>
Subject: Re: [dpdk-dev] [PATCH v5 2/4] net/ixgbe: add support of reset

07/07/2017 10:25, Thomas Monjalon:
> Hi,
> 
> 30/06/2017 12:12, Wei Dai:
> > +/*
> > + * Reest PF device.
> > + */
> > +static int
> > +ixgbe_dev_reset(struct rte_eth_dev *dev) {
> > +       int ret;
> > +
> > +       /* To avoid unexpected behavior in VF, disable PF reset */
> > +       if (dev->data->sriov.active)
> > +               return -ENOTSUP;
> > +
> > +       ret = eth_ixgbe_dev_uninit(dev);
> > +       if (ret)
> > +               return ret;
> > +
> > +       ret = eth_ixgbe_dev_init(dev);
> > +
> > +       return ret;
> > +}
> 
> rte_eth_dev_reset() just do
> +       rte_eth_dev_stop(port_id);
> +       ret = dev->dev_ops->dev_reset(dev);
> 
> and dev_reset() just do
> +       ret = eth_ixgbe_dev_uninit(dev);
> +       ret = eth_ixgbe_dev_init(dev);
> 
> It is doing one more thing, the check of SR-IOV.
> Unfortunately, this restriction is not documented.
> 
> This is the documentation of the new API:
> 
>  /**
> + * Reset a Ethernet device.
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + */
> +int rte_eth_dev_reset(uint8_t port_id);
> 
> It is really really too short.
> From the beginning of this proposal we are asking you to better 
> explain why this API is needed. It still does not appear in the doc.
> Are you adding it to offer a new service to DPDK application developpers?
> Or is it just a secret sauce that you will explain only to your customers?
> 
> This is what is expected to be documented:
> - why/when this API must be used
> - what the API will do
> - what is needed to do after

I would like to add that the description of the API must also help other PMD maintainers to implement it.
Adding a new op means more work for PMD maintainers, that's why they should understand the benefit and acknowledge it.
Ferruh, as the maintainer of next-net, please could you ask for feedbacks from other PMD maintainers?


More information about the dev mailing list