[dpdk-dev] Backporting rte_intr_ack

[dpdk-dev] Backporting rte_intr_ack

[David Marchand]

Hello guys,

The api rte_intr_ack that has been introduced to fix a race condition
observed with (at least) qede drivers/hw.
This is an experimental api in master but it still fixes a problem, so
I'd like to see this in stable branches.


Opinions?


Thanks.
-- 
David Marchand

Re: [dpdk-dev] Backporting rte_intr_ack

[Thomas Monjalon]

14/10/2019 17:55, David Marchand:
> The api rte_intr_ack that has been introduced to fix a race condition
> observed with (at least) qede drivers/hw.
> This is an experimental api in master but it still fixes a problem, so
> I'd like to see this in stable branches.

This is more a driver interface than an API.

> Opinions?

If it comes with a fix in a driver, I think it is worth backporting.

Re: [dpdk-dev] Backporting rte_intr_ack

[Kevin Traynor]

On 19/11/2019 10:40, Thomas Monjalon wrote:
> 14/10/2019 17:55, David Marchand:
>> The api rte_intr_ack that has been introduced to fix a race condition
>> observed with (at least) qede drivers/hw.
>> This is an experimental api in master but it still fixes a problem, so
>> I'd like to see this in stable branches.
> 
> This is more a driver interface than an API.
> 
>> Opinions?
> 
> If it comes with a fix in a driver, I think it is worth backporting.
> 
> 

I think fine to backport as it solves an observed problem for qede.
However, a bit reluctant to update all the drivers to use it without
acks from their maintainers.

Discussed with David offline and idea to backport and only update qede
now. Other drivers can be updated if there is a request from
maintainers. How does it sound?

Re: [dpdk-dev] Backporting rte_intr_ack

[Thomas Monjalon]

22/11/2019 16:12, Kevin Traynor:
> On 19/11/2019 10:40, Thomas Monjalon wrote:
> > 14/10/2019 17:55, David Marchand:
> >> The api rte_intr_ack that has been introduced to fix a race condition
> >> observed with (at least) qede drivers/hw.
> >> This is an experimental api in master but it still fixes a problem, so
> >> I'd like to see this in stable branches.
> > 
> > This is more a driver interface than an API.
> > 
> >> Opinions?
> > 
> > If it comes with a fix in a driver, I think it is worth backporting.
> > 
> > 
> 
> I think fine to backport as it solves an observed problem for qede.
> However, a bit reluctant to update all the drivers to use it without
> acks from their maintainers.
> 
> Discussed with David offline and idea to backport and only update qede
> now. Other drivers can be updated if there is a request from
> maintainers. How does it sound?

It's better than nothing.
But it makes tracking of backports more difficult.
Is it a common practice to backport half of fixes?

Re: [dpdk-dev] Backporting rte_intr_ack

[Kevin Traynor]

On 22/11/2019 15:24, Thomas Monjalon wrote:
> 22/11/2019 16:12, Kevin Traynor:
>> On 19/11/2019 10:40, Thomas Monjalon wrote:
>>> 14/10/2019 17:55, David Marchand:
>>>> The api rte_intr_ack that has been introduced to fix a race condition
>>>> observed with (at least) qede drivers/hw.
>>>> This is an experimental api in master but it still fixes a problem, so
>>>> I'd like to see this in stable branches.
>>>
>>> This is more a driver interface than an API.
>>>
>>>> Opinions?
>>>
>>> If it comes with a fix in a driver, I think it is worth backporting.
>>>
>>>
>>
>> I think fine to backport as it solves an observed problem for qede.
>> However, a bit reluctant to update all the drivers to use it without
>> acks from their maintainers.
>>
>> Discussed with David offline and idea to backport and only update qede
>> now. Other drivers can be updated if there is a request from
>> maintainers. How does it sound?
> 
> It's better than nothing.

Not sure whether it should be opt-in or opt-out for driver maintainers,
but if there is some bug found in this new experimental API it can break
many drivers, so was airing on the side of no regression. Open to other
suggestions. Btw, it is not urgent, as we have time before next release.

> But it makes tracking of backports more difficult.

Yes, a little. We can have a separate 18.11 only qede patch and not
claim to backport the commit which updates all drivers.

> Is it a common practice to backport half of fixes?
> 

I don't remember it before where it all can apply.

>