On Wed, May 30, 2007 at 08:42:32PM +0200, Patrick McHardy wrote:
> 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. Doing a mod_timer or hrtimer_forward to push forward may add to the
complexity depending on how often TX happens.
Are the drivers really worried about exact timeouts here? Can we use rounding
for the timers that are more than a second, at least?
Thanks,
Venki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
