[dpdk-dev] [PATCH v4 1/3] lib/librte_ether: add support for port reset

Zhao1, Wei wei.zhao1 at intel.com
Fri Apr 21 10:55:38 CEST 2017



> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Friday, April 21, 2017 10:28 AM
> To: Zhao1, Wei <wei.zhao1 at intel.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Mcnamara, John
> <john.mcnamara at intel.com>; dev at dpdk.org; Lu, Wenzhuo
> <wenzhuo.lu at intel.com>; Thomas Monjalon <thomas at monjalon.net>; Liu,
> Yu Y <yu.y.liu at intel.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/3] lib/librte_ether: add support for port
> reset
> 
> On Thu, Apr 20, 2017 at 09:17:24AM +0000, Zhao1, Wei wrote:
> > > > > Please explain exactly the responsibility of this function, and
> > > > > how it is different from calling stop/configure/start.
> > > >
> > > > In this reset feature, reset function can do the calling
> > > > stop/configure/start process, but also It can also do some restore
> > > > work for the port, for example, it can restore the added
> > > > parameters  of
> > > vlan,  mac_addrs, promisc_unicast_enabled falg and
> > > promisc_multicast_enabled flag.
> > > > Maybe , I should add this explanation in the patch comments or
> > > > function
> > > comments?
> > >
> > > I'm curious why we have to do save & restore for a reset operation.
> > > Why some configures have to be saved and restored? Doesn't "reset"
> > > literally means reset everything?
> > >
> >
> > Users maybe do not want to do a second configuration operation to waste
> time after reset which lost all previous configuration.
> > But he still want these configuration valid after reset.
> > So, save & restore can help them to save this process time and effort.
> >
> > > Even though, how do you tell what kind of configures need be
> > > restored and what should not? Again, even though, will all PMDs
> > > supports restoring the same set of configurations?
> > >
> >
> > Yes, this is hard to say what may be need and what may be not for user.
> > Now, the kinds of supported is list in patch set comment. And only i40e NIC
> support this feature.
> 
> Why it's the configurations listed in patch 2? Because they are requested by
> customers?
> 
> Is that all could be saved? If not, are you going to save & restore all possible
> configurations?
> 
> Assuming the configurations saved & restored may differ from different
> PMD drivers, how could you keep the consistency then? And judging that the
> application has no idea about the difference (yet it knows nothing about
> what kind of configurations will be saved), how could the application know
> that some configurations are not saved & restored by the driver that it has to
> do re-configuration by itself?
> 

Good idea, so maybe I should add some words in doc\guides\nics\i40e.rst to
Record which configurations are  saved  and restored by the PMD driver in reset function.
Which not list in that are recognized as not saved  and restored  by default.
Is that ok ?

> > > While looking at your reset implementation for i40e, it looks more
> > > complex than necessary: just thinking we have to call
> "xxx_queue_setup"
> > > for all PMDs.
> > >
> > > I'm thinking a simple hardware reset might be enough?
> > >
> > >     /* literally reset the hardware: reset everything */
> > >     rte_eth_reset(port)
> > >     {
> > >     	eth_dev->ops->reset();
> > >     }
> > >
> >
> > You mean just do a reset  and do not restore any configuration?
> > That may not meet the need for this feature from customer?
> 
> Right, I'm just aware of the configuration might be done by PF (but not only
> by the application), that the VF port may be not aware of those
> configurations. So the save & restore is needed. I don't quite like how it is
> done in this patch set though. I also don't think the API is well named: as said,
> reset should literally reset everything.
> 
> We may need think how to do it properly.
> 
> Thomas, Konstantin, what do you guys think of it?

So, your opinion is if it is named "reset", we had better do not do any restore work?
If we keep this restore feature, we had better change function name?
May be use the name "reset_and_restore" as function and feature name ?
 
> 
> 	--yliu


More information about the dev mailing list