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
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 problematic on
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 the timer
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
On Wed, 2015-05-27 at 11:23 -0400, Ido Yariv wrote:
Signed-off-by: Ido Yariv idox.ya...@intel.com
---
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
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
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 the
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 HZ100 anyway, always ensuring the
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-kernelm=143195210010666),
we should get this for free, no?
Well, on net and net-next tree
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 idox.ya...@intel.com
---
include/net/tcp.h | 9 +
net/ipv4/tcp_output.c | 2 +-
2 files changed, 10 insertions(+), 1
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 Nicholas Mc
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 leave
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 minimal
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
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 benchmarking
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 converted to
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
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 is the
18 matches
Mail list logo
