From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 30 May 2007 20:42:32 +0200

> Stephen Hemminger wrote:
> >>>Index: linux-2.6.22-rc-mm/net/sched/sch_generic.c
> >>>===================================================================
> >>>--- linux-2.6.22-rc-mm.orig/net/sched/sch_generic.c        2007-05-24 
> >>>11:16:03.000000000 -0700
> >>>+++ linux-2.6.22-rc-mm/net/sched/sch_generic.c     2007-05-25 
> >>>15:10:02.000000000 -0700
> >>>@@ -224,7 +224,8 @@
> >>>   if (dev->tx_timeout) {
> >>>           if (dev->watchdog_timeo <= 0)
> >>>                   dev->watchdog_timeo = 5*HZ;
> >>>-          if (!mod_timer(&dev->watchdog_timer, jiffies + 
> >>>dev->watchdog_timeo))
> >>>+          if (!mod_timer(&dev->watchdog_timer,
> >>>+                         round_jiffies(jiffies + dev->watchdog_timeo)))
> >>>                   dev_hold(dev);
> >>>   }
> >>> }
> >>
> >>Please cc netdev on net patches.
> >>
> >>Again, I worry that if people set the watchdog timeout to, say, 0.1 seconds
> >>then they will get one second, which is grossly different.
> >>
> >>And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
> >>significant, too.
> > 
> > 
> > Alternatively, we could change to a timer that is pushed forward after each
> > TX, maybe using hrtimer and hrtimer_forward().  That way the timer would
> > never run in normal case.
> 
> 
> It seems wasteful to add per-packet overhead for tx timeouts, which
> should be an exception. Do drivers really care about the exact
> timeout value? Compared to a packet transmission time its incredibly
> long anyways ..

I agree, this change is absolutely rediculious and is just a blind
cookie-cutter change made without consideration of what the code is
doing and what it's requirements are.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to