> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wodkowski, PawelX
> Sent: Tuesday, September 30, 2014 1:05 PM
> To: Wodkowski, PawelX; Richardson, Bruce
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel fun
> -Original Message-
> Pawe?
>
> > On Mon, Sep 29, 2014 at 10:11:38AM +, Wodkowski, PawelX wrote:
> > > > >
> > > > > Image how you will be damned by someone that not even notice you
> > change
> > > > > and he Is managing some kind of resource based on returned number of
> > > > > set
Pawe?
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, September 29, 2014 12:33
> To: Wodkowski, PawelX
> Cc: Ananyev, Konstantin; Neil Horman; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-
> safe:
>
&
Bruce
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> > thread-safe:
> >
> > > -Original Message-
> > > Pawe?
> > >
> > > > On Mon, Sep 29, 2014 at 10:11:38AM +, Wodkowsk
On Fri, Sep 26, 2014 at 02:13:55PM +, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Friday, September 26, 2014 2:40 PM
> > To: Wodkowski, PawelX
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev]
On Mon, Sep 29, 2014 at 10:11:38AM +, Wodkowski, PawelX wrote:
> > >
> > > Image how you will be damned by someone that not even notice you change
> > > and he Is managing some kind of resource based on returned number of
> > > set/canceled timers. If you suddenly start returning negative value
> >
> > Image how you will be damned by someone that not even notice you change
> > and he Is managing some kind of resource based on returned number of
> > set/canceled timers. If you suddenly start returning negative values how
> > those
> > application will behave? Silently changing returned va
> -Original Message-
> From: Wodkowski, PawelX
> Sent: Monday, September 29, 2014 7:41 AM
> To: Neil Horman; Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> thread-safe:
>
> > Y
On Mon, Sep 29, 2014 at 10:11:38AM +, Wodkowski, PawelX wrote:
> > >
> > > Image how you will be damned by someone that not even notice you change
> > > and he Is managing some kind of resource based on returned number of
> > > set/canceled timers. If you suddenly start returning negative value
> Yes, this is my concern exactly.
>
> > If that's so, then I suppose we can do: make alarm_cancel() to return a
> negative value for the case #3 (-EINPROGRESS or something).
> > Something like:
> > ...
> > if (ap->executing == 0) {
> >LIST_REMOVE(ap,next);
> > rte_free(ap);
> > coun
elX; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> > thread-safe:
> >
> > On Fri, Sep 26, 2014 at 06:07:14PM +, Ananyev, Konstantin wrote:
> > >
> > >
> > > > > As I remember the purpose of the patc
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Friday, September 26, 2014 8:39 PM
> To: Ananyev, Konstantin
> Cc: Wodkowski, PawelX; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> thread-s
> > As I remember the purpose of the patch was to fix the race condition inside
> > rte_alarm library.
> > I believe that the patch provided by Michal & Pawel fixes the issues you
> > discovered.
> > If you think, that is not the case, could you please provide a list of
> > remaining issues?
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Friday, September 26, 2014 4:02 PM
> To: Wodkowski, PawelX
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> thread-safe
On Fri, Sep 26, 2014 at 06:07:14PM +, Ananyev, Konstantin wrote:
>
>
> > > As I remember the purpose of the patch was to fix the race condition
> > > inside rte_alarm library.
> > > I believe that the patch provided by Michal & Pawel fixes the issues you
> > > discovered.
> > > If you think
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Friday, September 26, 2014 2:40 PM
> To: Wodkowski, PawelX
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> thread-safe:
>
> On Fri, Sep 26,
> > > Maybe I don't see something obvious? :)
>
> I think you're missing the fact that your patch doesn't do what you assert
> above
> either :)
Issue is not in setting alarms but canceling it. If you look closer to my patch
you
see that it address this issue (look at added *do { lock(); ;
> So basically cancel() just set ALARM_CANCELLED and leaves actual alarm
> deletion to the callback()?
> That was the thought, yes.
>
> > I think it is doable - but I don't see any real advantage with that
> > approach.
> > Yes, code will become a bit simpler, as we'll have one point when we rem
v at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> > thread-safe:
> >
> > On Fri, Sep 26, 2014 at 02:01:05PM +, Wodkowski, PawelX wrote:
> > > > > > Maybe I don't see something obvious? :)
> > > >
&g
On Fri, Sep 26, 2014 at 02:01:05PM +, Wodkowski, PawelX wrote:
> > > > Maybe I don't see something obvious? :)
> >
> > I think you're missing the fact that your patch doesn't do what you assert
> > above
> > either :)
>
> Issue is not in setting alarms but canceling it. If you look closer to
> >
> > diff --git a/lib/librte_eal/linuxapp/eal/eal_alarm.c
> > b/lib/librte_eal/linuxapp/eal/eal_alarm.c
> > index 480f0cb..73b6dc5 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal_alarm.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal_alarm.c
> > @@ -64,6 +64,9 @@
> > #define MS_PER_S 1000
> > #def
On Fri, Sep 26, 2014 at 06:33:12AM +, Wodkowski, PawelX wrote:
> > Given what you said above, I agree, at least in the current implementation.
> > It
> > still seems like theres a simpler solution that doesn't require all the
> > comparative gymnastics.
>
> Yes, there is simpler solution, bu
On Fri, Sep 26, 2014 at 12:37:54PM +, Wodkowski, PawelX wrote:
> > So basically cancel() just set ALARM_CANCELLED and leaves actual alarm
> > deletion to the callback()?
> > That was the thought, yes.
> >
> > > I think it is doable - but I don't see any real advantage with that
> > > approach
s at dpdk.org] On Behalf Of Neil Horman
> > > > Sent: Thursday, September 25, 2014 4:08 PM
> > > > To: Jastrzebski, MichalX K
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> > > > thre
> Given what you said above, I agree, at least in the current implementation.
> It
> still seems like theres a simpler solution that doesn't require all the
> comparative gymnastics.
Yes, there is simpler solution, but this solution involve recursive locking.
DPDK recursive spinlocks are no an o
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Thursday, September 25, 2014 6:24 PM
> To: Ananyev, Konstantin
> Cc: Jastrzebski, MichalX K; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> thread-safe:
>
> On Thu, Se
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, September 25, 2014 4:08 PM
> To: Jastrzebski, MichalX K
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> thread-s
Change alarm cancel function to thread-safe.
It eliminates a race between threads using rte_alarm_cancel and
rte_alarm_set.
Signed-off-by: Pawel Wodkowski
Reviewed-by: Michal Jastrzebski
---
lib/librte_eal/common/include/rte_alarm.h |3 +-
lib/librte_eal/linuxapp/eal/eal_alarm.
Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> > thread-safe:
> >
> > On Thu, Sep 25, 2014 at 01:56:08PM +0100, Michal Jastrzebski wrote:
> > > Change alarm cancel function to thread-safe.
> > > It elimin
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michal Jastrzebski
> Sent: Thursday, September 25, 2014 1:56 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe:
>
> Change alarm cancel function to thread-safe.
>
On Thu, Sep 25, 2014 at 01:56:08PM +0100, Michal Jastrzebski wrote:
> Change alarm cancel function to thread-safe.
> It eliminates a race between threads using rte_alarm_cancel and
> rte_alarm_set.
>
> Signed-off-by: Pawel Wodkowski
> Reviewed-by: Michal Jastrzebski
>
> ---
> lib/l
31 matches
Mail list logo
