patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Matan Azrad <matan@nvidia.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
	David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-stable] [PATCH] vdpa/mlx5: fix configuration mutex cleanup
Date: Tue, 26 Jan 2021 18:23:59 +0000	[thread overview]
Message-ID: <MW2PR12MB24922377F55CE97F6CD0D82EDFBC9@MW2PR12MB2492.namprd12.prod.outlook.com> (raw)
In-Reply-To: <a36db8e2-8455-dc8c-9ffc-eae72801a07e@redhat.com>



From: Maxime Coquelin
> On 1/26/21 11:45 AM, Matan Azrad wrote:
> >
> >
> > From: Maxime Coquelin
> >>> From: Maxime Coquelin
> >>>> On 1/14/21 4:23 PM, Matan Azrad wrote:
> >>>>>
> >>>>>
> >>>>> From: Maxime Coquelin
> >>>>>> On 1/14/21 2:09 PM, Matan Azrad wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> From: Maxime Coquelin
> >>>>>>>> Hi Matan,
> >>>>>>>>
> >>>>>>>> On 1/14/21 12:49 PM, Matan Azrad wrote:
> >>>>>>>>> Hi Maxime and David
> >>>>>>>>>
> >>>>>>>>> Thank you for Review.
> >>>>>>>>>
> >>>>>>>>> From: David Marchand
> >>>>>>>>>> On Fri, Jan 8, 2021 at 9:48 AM David Marchand
> >>>>>>>>>> <david.marchand@redhat.com> wrote:
> >>>>>>>>>>>> I wonder if it would be possible and cleaner to disable
> >>>>>>>>>>>> cancellation on the thread while the mutex is held?
> >>>>>>>>>
> >>>>>>>>> Yes, we can cause thread to return by some global variable sync.
> >>>>>>>>> It is the same logic.
> >>>>>>>>
> >>>>>>>> No, that was not my suggestion. My suggestion is to block the
> >>>>>>>> thread cancellation while in the critical section, using
> >>>> pthread_setcancelstate().
> >>>>>>>
> >>>>>>> Yes, Generally it is better to let the thread control his
> >>>>>>> cancellation, either
> >>>>>> cancel itself or enabling\disabling cancellations.
> >>>>>>>
> >>>>>>> I don't see a reason to wait for the thread in current logic -
> >>>>>>> the critical section
> >>>>>> is not important to be completed here.
> >>>>>>
> >>>>>> The reason I see is there are quite a few things done in this
> >>>>>> critical section. And if tomorrow someone add new things in it,
> >>>>>> he may not know the thread can be cancelled at any time, which
> >>>>>> could cause
> >>>> hard to debug issues.
> >>>>>
> >>>>> As I said, here it is not needed, this thread designed just to
> >>>>> cause guest
> >>>> notifications.
> >>>>>
> >>>>> The optional future developer mistake can be done also outside the
> >>>>> critical
> >>>> section in in any other place - we cannot protect it.
> >>>>>
> >>>>> The design choice is to close the thread fast.
> >>>>
> >>>> But why is it so urgent that it cannot been stopped cleanly?
> >>>> I don't think it would add seconds delay by doing it in a clean way.
> >>>
> >>> We have system calls there per queue.
> >>> No need this optional delay just because of mutex cleaning.
> >>
> >> OK, up to you...
> >>
> >> And what about the timer lock?
> >
> > Existing code initiates it before reusing...
> 
> Ok, so why not applying same logic for both mutexes?

Different dependencies, different usage.

Timer timer lock is more tied to the poll thread usage, this patch mutex has more usage, not only for the poll thread management.

> 
> > Thanks.
> >
> >>
> >>>
> >>>
> >>>> Thanks,
> >>>> Maxime
> >>>>
> >>>>>>> We just want to close the thread and to clean the mutex.
> >>>>>>>
> >>>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>> IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is
> >>>>>>>>>> applied, adding pthread_t to the list of types that are not
> >>>>>>>>>> required to be arithmetic types, thus allowing pthread_t to
> >>>>>>>>>> be defined as a
> >> structure.
> >>>>>>>>>>
> >>>>>>>>>> It would be better to leave pthread_t alone and not interpret it:
> >>>>>>>>>>
> >>>>>>>>>> if (priv->timer_tid) {
> >>>>>>>>>>     pthread_cancel(priv->timer_tid);
> >>>>>>>>>>     pthread_join(priv->timer_tid, &status); }
> >>>>>>>>>> priv->timer_tid = 0;
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm not sure why you think it is better in this specific case.
> >>>>>>>>> The cancellation will close the thread in faster way, no need
> >>>>>>>>> to wait for the
> >>>>>>>> thread to close itself.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> David Marchand
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >


  reply	other threads:[~2021-01-26 18:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  6:43 Matan Azrad
2021-01-07 18:09 ` Maxime Coquelin
2021-01-08  8:48   ` David Marchand
2021-01-14  8:34     ` David Marchand
2021-01-14 11:49       ` Matan Azrad
2021-01-14 12:38         ` Maxime Coquelin
2021-01-14 13:09           ` Matan Azrad
2021-01-14 14:27             ` Maxime Coquelin
2021-01-14 15:23               ` Matan Azrad
2021-01-21 10:46                 ` Maxime Coquelin
2021-01-21 20:13                   ` Matan Azrad
2021-01-26 10:22                     ` Maxime Coquelin
2021-01-26 10:45                       ` Matan Azrad
2021-01-26 13:00                         ` Maxime Coquelin
2021-01-26 18:23                           ` Matan Azrad [this message]
2021-01-27 10:45 ` Maxime Coquelin
2021-01-27 12:01 ` Maxime Coquelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW2PR12MB24922377F55CE97F6CD0D82EDFBC9@MW2PR12MB2492.namprd12.prod.outlook.com \
    --to=matan@nvidia.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).