[dpdk-dev] [PATCH 2/2] bond: add mode 4 support

[Neil Horman]

On Mon, Sep 22, 2014 at 06:26:21AM +0000, Wodkowski, PawelX wrote:
> > I think that will work, but I believe you're making it more complicated (and
> > less reusable) than it needs to be.  What I think you really need to do is
> > create a new rte api call, rte_eal_alarm_cancel_sync (something like the
> > equivalent of del_timer_sync in linux, that wraps up the
> > while(rte_eal_alarm_cancel(...) == 0) {rte_pause} in its own function (so other
> > call sites can use it, as I don't think this is an uncommon problem), Then just
> > create a bonding-internal state flag to signal the periodic callback that it
> > shouldn't re-arm the timer.  That way all you have to do is set the flag, and
> > call rte_eal_alarm_cancel_sync, and you're done.  And other applications will be
> > able to handle this common type of operation as well
> > 
> > Neil
> 
> I agree with you that alarms should be upgraded but this need to discussed and 
> tested. Now there is not time for that.
> 
Nak, thats a completely broken argument.  I've just demonstrated to you a race
condition in the driver you are submitting.  Granted it stems from a design
lmitation in the alarm subsystem, but its what we all have to work with, and we
can work around it and make the driver safe.  To say there is "no time" to fix
it, implies to me that you care more about just slamming your code in than
making anything work properly.  What exactly is your rush that makes you think
its more important for the code to be merged than fixing it to work correctly?
Neil