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

[Ferruh Yigit <ferruh.yigit@intel.com>]

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.

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