Re: [PATCH 1/2] eal/linux: fix VFIO hotplug with multiprocess

[Kevin Traynor <ktraynor@redhat.com>]

On 02/10/2024 14:31, David Marchand wrote:
> On Tue, Sep 17, 2024 at 10:20 AM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
>> On 9/16/24 14:30, David Marchand wrote:
>>> At the moment, if VFIO is not available at DPDK init, it won't be
>>> available unless a subsequent rte_vfio_enable() is done.
>>>
>>> Yet, even if rte_vfio_enable() is called again in primary and secondary
>>> processes, a secondary process will never get to know that VFIO has been
>>> enabled in the primary process as the MP requests handler is only
>>> registered in EAL init.
>>>
>>> On the other hand, moving the MP requests handler registration earlier
>>> in EAL init is ok, as secondary process are supposed to be waiting on
>>> eal_mcfg_wait_complete() until the primary process calls
>>> eal_mcfg_complete().
>>>
>>> Move vfio_mp_sync_setup() in rte_vfio_enable().
>>>
>>> Besides, rte_eal_vfio_setup() is useless and its name with a rte_ prefix
>>> is ambiguous as it gives the impression it is an exported/public symbol.
>>> Remove it and directly call rte_vfio_enable() where needed.
>>>
>>> Signed-off-by: David Marchand <david.marchand@redhat.com>
>>> ---
>>>   lib/eal/linux/eal.c      | 18 +-----------------
>>>   lib/eal/linux/eal_vfio.c |  9 ++++++---
>>>   2 files changed, 7 insertions(+), 20 deletions(-)
>>>
>>
>> Should it be considered as a fix, and so a candidate for stable?
>> Or do you think it is too risky to change the behaviour?
> 
> Cc: stable maintainers (fyi)
> 
> I don't think it is risky: existing applications which relied on multi
> process had no choice but to make sure VFIO was properly setup before
> DPDK init.
> Yet, a change in behavior impact is always hard to estimate.
> 
> (same comment for the second patch of the series)
> 
> 

They seem borderline fixes for usability. I think it's a good candidate
for 22.11/23.11.

For 21.11, it is the last release and the behaviour has been like that
for 3 years, so would probably skip that one.