From: Ido Yariv
> Sent: 28 May 2015 05:37
...
> +/* Convert msecs to jiffies, ensuring that the return value is at least 2
> + * jiffies.
> + * This can be used when setting tick-based timers to guarantee that they
> won't
> + * expire right away.
> + */
> +static inline unsigned long tcp_safe_mse
Hi Eric,
On Wed, May 27, 2015 at 03:15:26PM -0400, Ido Yariv wrote:
> Hi Eric,
>
> On Wed, May 27, 2015 at 10:24:16AM -0700, Eric Dumazet wrote:
> > On Wed, 2015-05-27 at 12:54 -0400, Ido Yariv wrote:
> > > Hi Eric,
> >
> > > That's a nice optimization ;)
> > >
> > > However, I think that with
Hi Eric,
On Wed, May 27, 2015 at 10:24:16AM -0700, Eric Dumazet wrote:
> On Wed, 2015-05-27 at 12:54 -0400, Ido Yariv wrote:
> > Hi Eric,
>
> > That's a nice optimization ;)
> >
> > However, I think that with Nicholas Mc Guire's recent changes to
> > msecs_to_jiffies (http://marc.info/?l=linux-k
On Wed, 2015-05-27 at 12:54 -0400, Ido Yariv wrote:
> Hi Eric,
> That's a nice optimization ;)
>
> However, I think that with Nicholas Mc Guire's recent changes to
> msecs_to_jiffies (http://marc.info/?l=linux-kernel&m=143195210010666),
> we should get this for free, no?
Well, on net and net-nex
Hi Eric,
On Wed, May 27, 2015 at 09:23:36AM -0700, Eric Dumazet wrote:
> On Wed, 2015-05-27 at 11:23 -0400, Ido Yariv wrote:
>
> > Signed-off-by: Ido Yariv
> > ---
> > include/net/tcp.h | 9 +
> > net/ipv4/tcp_output.c | 2 +-
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
On Wed, 2015-05-27 at 11:23 -0400, Ido Yariv wrote:
> Signed-off-by: Ido Yariv
> ---
> include/net/tcp.h | 9 +
> net/ipv4/tcp_output.c | 2 +-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 2bb2bad..86090b6 100644
>
Hi Eric,
On Wed, May 27, 2015 at 07:56:25AM -0700, Eric Dumazet wrote:
> On Wed, 2015-05-27 at 10:40 -0400, Ido Yariv wrote:
>
> > HZ=100 is used on some embedded platforms, so it's still something we
> > have to deal with unfortunately..
> >
> > Since the '2' here is a lower bound, and msecs_to
On Wed, 2015-05-27 at 10:40 -0400, Ido Yariv wrote:
> HZ=100 is used on some embedded platforms, so it's still something we
> have to deal with unfortunately..
>
> Since the '2' here is a lower bound, and msecs_to_jiffies(10) will
> return values greater than 2 for HZ>100 anyway, always ensuring
Hi Eric,
On Wed, May 27, 2015 at 06:41:17AM -0700, Eric Dumazet wrote:
> On Wed, 2015-05-27 at 11:36 +, David Laight wrote:
> > From: Of Ido Yariv
> > > Sent: 26 May 2015 21:17
> > > The Tail Loss Probe RFC specifies that the PTO value should be set to
> > > max(2 * SRTT, 10ms), where SRTT is
On Wed, 2015-05-27 at 11:36 +, David Laight wrote:
> From: Of Ido Yariv
> > Sent: 26 May 2015 21:17
> > The Tail Loss Probe RFC specifies that the PTO value should be set to
> > max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time.
> >
> > The PTO value is converted to jiffies, so t
From: Of Ido Yariv
> Sent: 26 May 2015 21:17
> The Tail Loss Probe RFC specifies that the PTO value should be set to
> max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time.
>
> The PTO value is converted to jiffies, so the timer may expire
> prematurely.
>
> This is especially problema
The Tail Loss Probe RFC specifies that the PTO value should be set to
max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time.
The PTO value is converted to jiffies, so the timer may expire
prematurely.
This is especially problematic on systems in which HZ <= 100, so work
around this by s
Hi Eric,
On Tue, May 26, 2015 at 11:25:21AM -0700, Eric Dumazet wrote:
> On Tue, 2015-05-26 at 13:55 -0400, Ido Yariv wrote:
>
> >
> > The platform this was tested on was an embedded platform with a wifi
> > module (11n, 20MHZ). The other end was a computer running Windows, and
> > the benchmark
On Tue, 2015-05-26 at 13:55 -0400, Ido Yariv wrote:
>
> The platform this was tested on was an embedded platform with a wifi
> module (11n, 20MHZ). The other end was a computer running Windows, and
> the benchmarking software was IxChariot.
> The whole setup was running in a shielded box with min
On Tue, 2015-05-26 at 13:55 -0400, Ido Yariv wrote:
> Hi Eric,
>
>
> I understand, and I also suspect that having it expire after 9ms will
> have very little impact, if at all.
>
> Since it mainly affects HZ=100 systems, we can simply go with having at
> least 2 jiffies on these systems, and le
Hi Eric,
On Tue, May 26, 2015 at 10:13:40AM -0700, Eric Dumazet wrote:
> On Tue, 2015-05-26 at 13:02 -0400, Ido Yariv wrote:
> > Hi Eric,
> >
> > On Tue, May 26, 2015 at 09:23:55AM -0700, Eric Dumazet wrote:
> > > Have you really hit an issue, or did you send this patch after all these
> > > msec
On Tue, 2015-05-26 at 13:02 -0400, Ido Yariv wrote:
> Hi Eric,
>
> On Tue, May 26, 2015 at 09:23:55AM -0700, Eric Dumazet wrote:
> > On Tue, 2015-05-26 at 10:25 -0400, Ido Yariv wrote:
> > > The Tail Loss Probe RFC specifies that the PTO value should be set to
> > > max(2 * SRTT, 10ms), where SRTT
Hi Eric,
On Tue, May 26, 2015 at 09:23:55AM -0700, Eric Dumazet wrote:
> On Tue, 2015-05-26 at 10:25 -0400, Ido Yariv wrote:
> > The Tail Loss Probe RFC specifies that the PTO value should be set to
> > max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time.
> >
> > The PTO value is conv
On Tue, 2015-05-26 at 10:25 -0400, Ido Yariv wrote:
> The Tail Loss Probe RFC specifies that the PTO value should be set to
> max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time.
>
> The PTO value is converted to jiffies, so the timer might expire
> prematurely. This is especially prob
The Tail Loss Probe RFC specifies that the PTO value should be set to
max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time.
The PTO value is converted to jiffies, so the timer might expire
prematurely. This is especially problematic on systems in which HZ=100.
To work around this issue
20 matches
Mail list logo
