Re: [dpdk-dev] [PATCH v3 2/2] ethdev: device configuration enhancement

["Lu, Wenzhuo" <wenzhuo.lu@intel.com>]

Hi Ferruh,

> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, November 13, 2018 5:41 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: device configuration
> enhancement
> 
> On 11/13/2018 12:46 AM, Lu, Wenzhuo wrote:
> > Hi Ferruh,
> >
> >
> >> -----Original Message-----
> >> From: Yigit, Ferruh
> >> Sent: Saturday, November 10, 2018 5:10 AM
> >> To: Andrew Rybchenko <arybchenko@solarflare.com>; Lu, Wenzhuo
> >> <wenzhuo.lu@intel.com>; dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: device configuration
> >> enhancement
> >>
> >> On 11/8/2018 6:25 AM, Andrew Rybchenko wrote:
> >>> On 11/8/18 5:09 AM, Wenzhuo Lu wrote:
> >>>> The new configuration is stored during the process.
> >>>> But the process may fail. We better rolling the configuration back
> >>>> as the new one doesn't take effect.
> >>>>
> >>>> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> >>>
> >>> I would say that the order is wrong. We should fix this bug first
> >>> and the changeset should have appropriate Fixes tags.
> >>> I think this bug is older and should be fixed first.
> >>> Then the second bug should be fixed without this one present.
> >>
> >> Logically suggested order make sense I agree, but both patches are
> >> fixing defect and order won't help backporting them [1], so no strong
> >> opinion about order.
> >>
> >> Overall this patch should be converted into fix defect with proper
> >> Fixes tag independent from order.
> >>
> >> Wenzhuo, what do you think? I would like to get this one for rc3!
> >>
> >>
> >> [1]
> >> This is older defect but I believe can't be backported cleanly into
> >> older stable trees because of "PMD-tuned Tx/Rx parameters" patches in
> the middle.
> >> Downside having this first prevents other patch to backported to
> >> closer stable trees.
> >>
> >> Also having this patch first will require additional return value
> >> update in some checks (nb_tx_q && nb_rx_q checks) in next patch, so
> >> for separation fixes this order is clearer.
> > Yes, to my opinion, these 2 are separate patches. Actually there's no order
> between them. I put them together only because we have had a mixed
> discussion.
> 
> Yes they are not depends each other. Thinking twice adding first patch will
> leave the code in a state more open the defect fixed in second patch. But by
> fixing defect first second fix can be applied without having that open.
> 
> I will send a new version of the set.
Thanks a lot! Very appreciate for your help!

> 
> > I didn't put a fix prefix because it's hard to add a fix tag for it. We know it
> has the problem from the beginning, so after some changes this patch
> cannot  be backported.
> >