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. > 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. >
