On Thu, Dec 5, 2019 at 10:25 PM Björn Töpel <bjorn.topel@xxxxxxxxx> wrote:
>
> On 2019-12-06 00:21, William Tu wrote:
> > Hi,
> >
> > While testing XSK using OVS, we hit an issue when create xsk,
> > destroy xsk, create xsk in a short time window.
> > The call to xsk_socket__create returns EBUSY due to
> > xsk_bind
> > xdp_umem_assign_dev
> > xdp_get_umem_from_qid --> return EBUSY
> >
> > I found that when everything works, the sequence is
> > <ovs creates xsk>
> > xsk_bind
> > xdp_umem_assign_dev
> > <ovs destroy xsk> ...
> > xsk_release
> > xsk_destruct
> > xdp_umem_release_deferred
> > xdp_umem_release
> > xdp_umem_clear_dev --> avoid the error above
> >
> > But sometimes xsk_destruct has not yet called, the
> > next call to xsk_bind shows up, ex:
> >
> > <ovs creates xsk>
> > xsk_bind
> > xdp_umem_assign_dev
> > <ovs destroy xsk> ...
> > xsk_release
> > xsk_bind
> > xdp_umem_assign_dev
> > xdp_get_umem_from_qid (failed!)
> > ....
> > xsk_destruct
> >
> > Is there a way to make sure the previous xsk is fully cleanup,
> > so we can safely call xsk_socket__create()?
> >
>
> Yes, the async cleanup is annoying. I *think* it can be done
> synchronous, since the map doesn't linger on a sockref anymore --
> 0402acd683c6 ("xsk: remove AF_XDP socket from map when the socket is
> released").
>
> So, it's not a race, it just asynch. :-(
>
Yes, thank you for quick response.
Now I can work around it by adding a sleep.
Look forward to your patch.
Thanks
William
|