Re: [dpdk-dev] [PATCH v2 1/2] librte_ether: ensure not overwrite device data in mp app

["Kerlin, MarcinX" <marcinx.kerlin@intel.com>]

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, September 23, 2016 4:13 PM
> To: Kerlin, MarcinX <marcinx.kerlin@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org; De Lara
> Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 1/2] librte_ether: ensure not overwrite
> device data in mp app
> 
> 2016-09-22 14:11, Kerlin, MarcinX:
> > Hi Reshma,
> >
> > From: Pattan, Reshma
> > >
> > > Hi Marcin,
> > >
> > > >  /**
> > > >   * @internal
> > > > + * Returns a shared device data slot specified by the unique identifier
> name.
> > > > + *
> > > > + * @param	name
> > > > + *  The pointer to the Unique identifier name for each shared
> > > > +Ethernet device
> > > > + *  between multiple processes.
> > > > + * @return
> > > > + *   - The pointer to the device data slot, on success. NULL on error
> > > > + */
> > > > +struct rte_eth_dev_data *rte_eth_dev_data_allocated(const char
> > > > +*name);
> > >
> > > This should be static function in source file rather than public function.
> > > And name can be rte_eth_dev_get_dev_by_name() something like that?
> >
> > 1) Yes should be, this function is not using outside lib now, thanks
> > 2) My proposition is rte_eth_dev_get_dev_data_by_name(), because it is
> related with device data structure.. Do you have any objections Thomas?
> 
> No objection on the name.
> But the whole patch looks strange.
> 
> > I am waiting for still some objections and then prepare v3
> 
> Please could you better state the problem you want to solve in the messages of
> each v3 patch?
> I'll try to understand and review the v3.

you're right, description without example is hard to quickly understand.

I added to cover letter how to reproduce the bug, how it affects on applications and 
how it is repaired in patch.  

I hope that it will clarify problem.

Regards,
Marcin
> 
> Thanks