>-----Original Message----- >From: David Marchand <david.march...@redhat.com> >Sent: Friday, July 8, 2022 1:43 PM >To: abhimanyu.sa...@xilinx.com; vsriv...@xilinx.com >Cc: Maxime Coquelin <maxime.coque...@redhat.com>; dev <dev@dpdk.org>; >Xia, Chenbo <chenbo....@intel.com>; Andrew Rybchenko ><andrew.rybche...@oktetlabs.ru>; Saini, Abhimanyu ><abhimanyu.sa...@amd.com> >Subject: Re: [PATCH] vdpa/sfc: resolve race between libvhost and dev_conf > >CAUTION: This message has originated from an External Source. Please use >proper judgment and caution when opening attachments, clicking links, or >responding to this email. > > >Hello Abhimanyu, Vijay, > >On Thu, Jul 7, 2022 at 2:38 PM Maxime Coquelin ><maxime.coque...@redhat.com> wrote: >> On 7/6/22 11:24, abhimanyu.sa...@xilinx.com wrote: >> > From: Abhimanyu Saini <absa...@amd.com> >> > >> > libvhost calls dev_conf() before prosessing the >> > VHOST_USER_SET_VRING_CALL message for the last VQ. So this message >> > is processed after dev_conf() returns. >> > >> > However, the dev_conf() function spawns a thread to set >> > rte_vhost_host_notifier_ctrl() before returning control to libvhost. >> > This parallel thread in turn invokes get_notify_area(). >> > To get the notify_area, the vdpa driver needs to query the HW and >> > for this query it needs an enabled VQ. >> > >> > But at the same time libvhost is processing the last >> > VHOST_USER_SET_VRING_CALL, and to do that it disables the last VQ. >> > >> > Hence there is a race b/w the libvhost and the vdpa driver. >> > >> > To resolve this race condition, query the HW and cache notify_area >> > inside dev_conf() instead of doing it the parallel thread. >> > >> > Signed-off-by: Abhimanyu Saini <absa...@amd.com> >> > --- >> > drivers/vdpa/sfc/sfc_vdpa_ops.c | 36 ++++++++++++++++++------------------ >> > drivers/vdpa/sfc/sfc_vdpa_ops.h | 1 + >> > 2 files changed, 19 insertions(+), 18 deletions(-) >> > >> >> During today's Release status meeting, Andrew mentioned that this >> patch has been for a log time already in your internal tree. >> >> So it gives a bit of confidence in taking it in -rc4. > >- But it is neither reviewed, nor acked by the driver maintainer. > >Vijay, as this driver maintainer, your opinion matters. >We are in rc4 stage and we merge only critical fixes now. >There won't be much time to test this fix once merged (and I am not talking >about fixing a regression). > >Are you confident with this fix? Yes.
>is it required for the 22.07 release? It is not a blocker issue, but it would be good to have in this release. >If we don't get an answer, the safer is to let those fixes slip to a next >release. > > >- Besides, I see there is a new fix for some sfc driver. >https://patches.dpdk.org/project/dpdk/patch/20220708073702.29391-1- >asa...@xilinx.com/ >The same questions will be asked. > > >-- >David Marchand Acked-by: Vijay Srivastava <vij...@amd.com>
