Hi Ferruh, > -----Original Message----- > From: Yigit, Ferruh > Sent: Tuesday, November 13, 2018 5:41 PM > To: Lu, Wenzhuo <wenzhuo...@intel.com>; Andrew Rybchenko > <arybche...@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 <arybche...@solarflare.com>; Lu, Wenzhuo > >> <wenzhuo...@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...@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. > >