On 02/10/2024 14:31, David Marchand wrote: > On Tue, Sep 17, 2024 at 10:20 AM Maxime Coquelin > <maxime.coque...@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.march...@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.
