On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:
> With the skge driver there seems to be some sort of problem to work
> in a system with memory above the 4 GB of PCI address space.
The chipset (apparently) doesn't deal with bus addresses over 4GB even
though the MAC does.
I guess t
On Mon, 19 Feb 2007 15:55:19 -0800 [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8042
>
>Summary: Cisco VPN Client cannot connect using TCP with Intel
> 82573L NIC
> Kernel Version: 2.6.18.6
> Status: NEW
> Severity
Angelo P. Castellani wrote:
John Heffner ha scritto:
Note the patch is compile-tested only! I can do some real testing if
you'd like to apply this Dave.
The date you read on the patch is due to the fact I've splitted this
patchset into 2 diff files. This isn't compile-tested only, I've used
t
Hi,
More fix is needed for __xfrm6_bundle_create().
Signed-off-by: Noriaki TAKAMIYA <[EMAIL PROTECTED]>
Acked-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
--
fixed to set fl_tunnel.fl6_src correctly in xfrm6_bundle_create().
---
net/ipv6/xfrm6
From: Chris Snook <[EMAIL PROTECTED]>
Remove irq_sem from ixgb. Currently untested, but similar to tested patches
on atl1 and e1000.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--
diff -urp linux-2.6.20-git14.orig/drivers/net/ixgb/ixgb.h
linux-2.6.20-git14/drivers/net/ixgb/ixgb.h
--- linux-2.
From: Chris Snook <[EMAIL PROTECTED]>
Remove unnecessary irq_sem accounting from e1000. Tested with no problems.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--
diff -urp linux-2.6.20-git14.orig/drivers/net/e1000/e1000.h
linux-2.6.20-git14/drivers/net/e1000/e1000.h
--- linux-2.6.20-git14.orig/
Chris Snook wrote:
Hey folks --
While digging through the atl1 source, I was troubled by the code using
irq_sem. I did some digging and found the same code in e1000 and ixgb. I'm
not entirely sure what it was originally intended to do, but it doesn't seem
to be doing anything useful now,
From: Chris Snook <[EMAIL PROTECTED]>
Remove unnecessary irq_sem code from atl1 driver. Tested with no problems.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
--
diff -urp linux-2.6.20-git14.orig/drivers/net/atl1/atl1.h
linux-2.6.20-git14/drivers/n
Hey folks --
While digging through the atl1 source, I was troubled by the code using
irq_sem. I did some digging and found the same code in e1000 and ixgb. I'm
not entirely sure what it was originally intended to do, but it doesn't seem
to be doing anything useful now, except possibly locki
This patch removes checksum offload feature in mcp65 chipsets as they
are not supported in hw.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-02-19 09:17:41.0 -0500
+++ new/drivers/net/forcedeth.c 2007-02-19 09:19:43.0 -0500
@@ -5374
Robert Hancock wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s)
and may contain
There seems to be an issue when both MSI-X is enabled and NAPI is
configured. This patch disables MSI-X until the issue is root caused.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-02-19 09:17:02.0 -0500
+++ new/drivers/net/forcedeth.c 200
The napi poll routine was missing the call to the optimized rx process
routine. This patch adds the missing call for the optimized path.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-02-19 09:13:10.0 -0500
+++ new/drivers/net/forcedeth.c 20
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s) and
may contain
confidential information.
This patch moves the EXPORT_SYMBOL's from net/rxrpc/rxrpc_syms.c to the
files with the actual functions.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Nov 2006
net/rxrpc/Makefile |1 -
net/rxrpc/call.c |5 +
net/rxrpc/connection.
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc6-mm3:
>...
> +Fabric7-VIOC-driver.patch
>...
> netdev stuff
>...
This patch contains the following possible cleanups:
- remove dead #ifdef EXPORT_SYMTAB code
- no "inline" functions in C files - gcc kno
On Mon, Feb 05, 2007 at 06:01:42PM -0800, David Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Mon, 05 Feb 2007 16:30:53 -0800
>
> > From: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > Add proper prototypes for some functions in include/net/irda/irda.h
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTE
This patch contains the following possible cleanups:
- make needlessly global functions static
- #if 0 the following unused global functions:
- zd_chip.c: zd_ioread16()
- zd_chip.c: zd_ioread32()
- zd_chip.c: zd_iowrite16()
- zd_chip.c: zd_ioread32v()
- zd_chip.c: zd_read_mac_addr()
- z
On Tue, Feb 20, 2007 at 08:56:39AM +0900, takada wrote:
> /proc/cpuinfo with MediaGXm :
>
> processor : 0
> vendor_id : CyrixInstead
> cpu family: 5
> model : 5
> model name: Cyrix MediaGXtm MMXtm Enhanced
> stepping : 2
> cpu MHz : 199.750
> cache size
On Tue, Nov 28, 2006 at 11:47:19PM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 08:36:09 +0100
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote:
> > > On Fri, 24 Nov 2006 01:17:31 +0100
> > > Adrian Bunk <[EMAIL PROTECTED]> wrote
On Mon, Feb 19, 2007 at 06:45:48PM -0500, Lennart Sorensen wrote:
> It seems the problem actually occours when the receive descriptor ring
> is full. This seems to generate one (or sometimes more) descriptors in
> the ring which claim to be owned by the MAC, but at the head of the
> receive ring a
From: Roland Dreier <[EMAIL PROTECTED]>
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
Date: Mon, 19 Feb 2007 11:48:27 -0800
> > Does anyone know if there is any way to flush a cache line of the cpu to
> > force rereading system memory for a given address or address range?
>
> There is the
On Tue, 20 Feb 2007 00:14:47 +0100
bert hubert <[EMAIL PROTECTED]> wrote:
> Hi people,
>
> I'm trying to save people the cost of buying extra servers by making
> PowerDNS (GPL) ever faster, but I've hit a rather fundamental problem.
>
> Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3G
John Heffner ha scritto:
Note the patch is compile-tested only! I can do some real testing if
you'd like to apply this Dave.
The date you read on the patch is due to the fact I've splitted this
patchset into 2 diff files. This isn't compile-tested only, I've used
this piece of code for about 3
On Mon, Feb 19, 2007 at 05:29:20PM -0500, Lennart Sorensen wrote:
> I just noticed, it seems almost all these problems occour right at the
> start of transfers when the tcp window size is still being worked out
> for the connection speed, and I am seeing the error count go up in
> ifconfig for the
Hi people,
I'm trying to save people the cost of buying extra servers by making
PowerDNS (GPL) ever faster, but I've hit a rather fundamental problem.
Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3GHz for a
non-blocking UDPv4 recvfrom() call, both on loopback and ethernet.
Linux 2.6.
On Mon, 2007-02-19 at 17:30 -0500, Pavel Roskin wrote:
> Johannes, would it be possible to commit patches faster, please? Now
> that I told Michael about git-update-server-info, his changes are
> downloadable as soon as he makes a commit. wireless-dev.git, on the
> other hand, is a mess and has
On Mon, 2007-02-19 at 23:12 +0100, Johannes Berg wrote:
> On Mon, 2007-02-19 at 13:48 -0800, Alex Davis wrote:
> > I go the following Oops with the latest wireless-dev git when starting
> > wpa_supplicant:
> >
> > Feb 19 16:17:42 boss kernel: [ 377.359573] BUG: unable to handle kernel
> > NULL
On Mon, Feb 19, 2007 at 05:18:45PM -0500, Lennart Sorensen wrote:
> On Mon, Feb 19, 2007 at 03:11:36PM -0500, Lennart Sorensen wrote:
> > I have been poking at things with firescope to see if the MAC is
> > actually writing to system memory or not.
> >
> > The entry that it gets stuch on is _alway
On Mon, 2007-02-19 at 13:48 -0800, Alex Davis wrote:
> I go the following Oops with the latest wireless-dev git when starting
> wpa_supplicant:
Wireless topics moved from this list to [EMAIL PROTECTED]
Broadcom drivers are discussed in [EMAIL PROTECTED]
wireless-dev is horribly broken, and the fi
On Mon, Feb 19, 2007 at 03:11:36PM -0500, Lennart Sorensen wrote:
> I have been poking at things with firescope to see if the MAC is
> actually writing to system memory or not.
>
> The entry that it gets stuch on is _always_ entry 0 in the rx_ring.
> There does not appear to be any exceptions to t
On Mon, 2007-02-19 at 13:48 -0800, Alex Davis wrote:
> I go the following Oops with the latest wireless-dev git when starting
> wpa_supplicant:
>
> Feb 19 16:17:42 boss kernel: [ 377.359573] BUG: unable to handle kernel NULL
> pointer dereference
> at virtual address 0002
Probably caused b
I go the following Oops with the latest wireless-dev git when starting
wpa_supplicant:
Feb 19 16:17:42 boss kernel: [ 377.359573] BUG: unable to handle kernel NULL
pointer dereference
at virtual address 0002
Feb 19 16:17:42 boss kernel: [ 377.359641] printing eip:
Feb 19 16:17:42 boss ker
On Thu, Feb 15, 2007 at 03:45:23PM -0800, Jay Vosburgh wrote:
>
> For the short term, yes, I don't have any disagreement with
> switching the timer based stuff over to workqueues. Basically a one for
> one replacement to get the functions in a process context and tweak the
> locking.
I did
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
>
> My experiment shows almost 400 nsecs without _any_ locks - they are
> removed completely - it is pure hash selection/list traverse time.
Are you sure you're not measuring TLB misses too? In user space
you likely use 4K pages. The kernel would use 2
Cc: list trimmed.
Jarek Poplawski <[EMAIL PROTECTED]> :
> On Fri, Feb 16, 2007 at 09:20:34PM +0100, Francois Romieu wrote:
[...]
> > Btw, the thread runs every 3*HZ at most.
>
> You are right (mostly)! But I think rtnl_lock is special
> and should be spared (even this 3*HZ) and here it's used
> f
On Thursday 08 February 2007 1:01 am, Zhu Yi wrote:
> A generic requirement for dynamic power management is the hardware
> resource should not be touched when you put it in a low power state.
That is in no way a "generic" requirement. It might apply specifically
to one ipw2100 low power state ..
I'd prefer to make it apply automatically across all congestion controls
that do slow-start, and also make the max_ssthresh parameter
controllable via sysctl. This patch (attached) should implement this.
Note the default value for sysctl_tcp_max_ssthresh = 0, which disables
limited slow-start.
This patch provides code paths which allow the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool. Any PHYs that are present can be accessed via the
Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI
bus with an oversized EEPROM using a direct MII<->MII connection with no
PHY. This patch adds a new device table entry supporting these cards.
Signed-Off-By: Mark Brown <[EMAIL PROTECTED]>
---
This revision removes extra br
These patches add support for the Aculab E1/T1 cPCI carrier card to the
natsemi driver. The first patch provides support for using the MII port
with no PHY and the second adds the quirks required to detect and
configure the card.
This revision should address the issues raised by Jeff over the wee
On Fri, Feb 16, 2007 at 04:01:57PM -0500, Lennart Sorensen wrote:
> eth1: netif_receive_skb(skb)
> eth1: netif_receive_skb(skb)
> eth1: pcnet32_poll: pcnet32_rx() got 16 packets
> eth1: base: 0x05215812 status: 0310 next->status: 0310
> eth1: netif_receive_skb(skb)
> eth1: netif_receive_skb(skb)
>
On Mon, Feb 19, 2007 at 11:48:27AM -0800, Roland Dreier wrote:
> > Does anyone know if there is any way to flush a cache line of the cpu to
> > force rereading system memory for a given address or address range?
>
> There is the "clflush" instruction, but not all x86 CPUs support it.
> You need
> Does anyone know if there is any way to flush a cache line of the cpu to
> force rereading system memory for a given address or address range?
There is the "clflush" instruction, but not all x86 CPUs support it.
You need to check the CPUID flag to know for sure (/proc/cpuinfo will
show a "clfl
On 19 Feb 2007 13:04:12 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
LRU tends to be hell for caches in MP systems, because it writes to
the cache lines too and makes them exclusive and more expensive.
That's why you let the hardware worry about LRU. You don't write to
the upper layers of the
On Mon, Feb 19, 2007 at 01:26:42PM -0500, Benjamin LaHaise wrote:
> On Mon, Feb 19, 2007 at 07:13:07PM +0100, Eric Dumazet wrote:
> > So even with a lazy hash function, 89 % of lookups are satisfied with less
> > than 6 compares.
>
> Which sucks, as those are typically going to be cache misses (c
On Mon, Feb 19, 2007 at 07:13:07PM +0100, Eric Dumazet wrote:
> So even with a lazy hash function, 89 % of lookups are satisfied with less
> than 6 compares.
Which sucks, as those are typically going to be cache misses (costing many
hundreds of cpu cycles). Hash chains fair very poorly under Do
On Monday 19 February 2007 16:14, Eric Dumazet wrote:
>
> Because O(1) is different of O(log(N)) ?
> if N = 2^20, it certainly makes a difference.
> Yes, 1% of chains might have a length > 10, but yet 99% of the lookups are
> touching less than 4 cache lines.
> With a binary tree, log(2^20) is 20.
On Monday 19 February 2007 15:25, Evgeniy Polyakov wrote:
> On Mon, Feb 19, 2007 at 03:14:02PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > > Forget about cache misses and cache lines - we have a hash table, only
> > > part of which is used (part for time-wait sockets, part for established
>
On Fri, 2007-02-16 at 09:42 -0800, Joe Perches wrote:
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Acked-By: Thomas Sailer <[EMAIL PROTECTED]>
Thanks a lot!
Tom
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Sat, Feb 17, 2007 at 11:11:13PM +0900, takada wrote:
> is it mean what doesn't help with doesn't call set_cx86_reoder()?
> this function disable to reorder at 0x4000: to 0x:.
> does pcnet32 access at out of above range?
>
> --- arch/i386/Kconfig.cpu~2007-02-05 03:44:54.0
On Mon, Feb 19, 2007 at 03:14:02PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > Forget about cache misses and cache lines - we have a hash table, only
> > part of which is used (part for time-wait sockets, part for established
> > ones).
>
> No you didnt not read my mail. Current ehash is n
On 17-02-2007 17:25, Evgeniy Polyakov wrote:
> On Fri, Feb 16, 2007 at 09:34:27PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
>> Otherwise we can extend select output mask to include hungup too
>> (getting into account that hungup is actually output event).
>
> This is another possible w
On Monday 19 February 2007 14:56, Evgeniy Polyakov wrote:
> On Mon, Feb 19, 2007 at 02:38:13PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Monday 19 February 2007 12:41, Evgeniy Polyakov wrote:
> > > > 1 microsecond ? Are you kidding ? We want no more than 50 ns.
> > >
> > > Theory again
Actually for socket code any other binary tree will work perfectly ok -
socket code does not have wildcards (except listening sockets), so it is
possible to combine all values into one search key used in flat
one-dimensional tree - it scales as hell and allows still very high
lookup time.
As of ca
On Mon, Feb 19, 2007 at 02:38:13PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Monday 19 February 2007 12:41, Evgeniy Polyakov wrote:
>
> > > 1 microsecond ? Are you kidding ? We want no more than 50 ns.
> >
> > Theory again.
>
>
> Theory is nice, but I personally prefer oprofile :)
> I
On Monday 19 February 2007 12:41, Evgeniy Polyakov wrote:
> > 1 microsecond ? Are you kidding ? We want no more than 50 ns.
>
> Theory again.
Theory is nice, but I personally prefer oprofile :)
I base my comments on real facts.
We *want* 50 ns tcp lookups (2 cache line misses, one with reader in
Andi Kleen writes:
> > If not, you loose.
>
> It all depends on if the higher levels on the trie are small
> enough to be kept in cache. Even with two cache misses it might
> still break even, but have better scalability.
Yes the trick to keep root large to allow a very flat tree and few
On Fri, Feb 16, 2007 at 09:20:34PM +0100, Francois Romieu wrote:
> Jarek Poplawski <[EMAIL PROTECTED]> :
...
> > > @@ -1603,18 +1605,21 @@ static void rtl8139_thread (struct work_struct
> > > *work)
> > > struct net_device *dev = tp->mii.dev;
> > > unsigned long thr_delay = next_tick;
> > >
On Sun, Feb 18, 2007 at 09:21:30PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov a e'crit :
> >On Sun, Feb 18, 2007 at 07:46:22PM +0100, Eric Dumazet
> >([EMAIL PROTECTED]) wrote:
> >>>Why anyone do not want to use trie - for socket-like loads it has
> >>>exactly constant sear
Since purpose is to reduce CWND, we prevent immediate growth. This
is not a major issue nor is "the correct way" specified anywhere.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_inpu
Because TCP is not in Loss state during FRTO recovery, fast
recovery could be triggered by accident. Non-SACK FRTO is more
robust than not yet included SACK-enhanced version (that can
receiver high number of duplicate ACKs with SACK blocks during
FRTO), at least with unidirectional transfers, but u
TCP without FRTO would be in Loss state with small cwnd. FRTO,
however, leaves cwnd (typically) to a larger value which causes
ssthresh to become too large in case RTO is triggered again
compared to what conventional recovery would do. Because
consecutive RTOs result in only a single ssthresh reduc
The description is overly verbose to avoid ambiguity between
"SACK enabled" and "SACK enhanced FRTO"
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/ip
Previously RETRANS bits were cleared on the entry to FRTO. We
postpone that into tcp_enter_frto_loss, which is really the
place were the clearing should be done anyway. This allows
simplification of the logic from a clearing loop to the head skb
clearing only.
Besides, the other changes made in th
Implements the SACK-enhanced FRTO given in RFC4138 using the
variant given in Appendix B.
RFC4138, Appendix B:
"This means that in order to declare timeout spurious, the TCP
sender must receive an acknowledgment for non-retransmitted
segment between SND.UNA and RecoveryPoint in algorithm s
To be honest, I'm not too sure how the reord stuff works in the
first place but this seems necessary.
When FRTO has been active, the one and only retransmission could
be unnecessary but the state and sending order might not be what
the sacktag code expects it to be (to work correctly).
Signed-off
The FRTO detection did not care how ACK pattern affects to cwnd
calculation of the conventional recovery. This caused incorrect
setting of cwnd when the fallback becames necessary. The
knowledge tcp_process_frto() has about the incoming ACK is now
passed on to tcp_enter_frto_loss() in allowed_segme
In addition, removed inline.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/tcp.h| 14 +-
net/ipv4/tcp_input.c | 13 +
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 5c472f2..572a77b 10
This interpretation comes from RFC4138:
"If the sender implements some loss recovery algorithm other
than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD
NOT be entered when earlier fast recovery is underway."
I think the RFC means to say (especially in the light of
Appendix B) t
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 309da3e..9fc7f66 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2551,11 +2551,11
FRTO controls cwnd when it still processes the ACK input or it
has just reverted back to conventional RTO recovery; the normal
rules apply when FRTO has reverted to standard congestion
control.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c | 18 +++---
1
Handles RFC4138 shortcoming (in step 2); it should also have case
c) which ignores ACKs that are not duplicates nor advance window
(opposite dir data, winupdate).
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c | 13 ++---
1 files changed, 10 insertions(+), 3 d
In case a latency spike causes more than one RTO, the later should not
cause the already reduced ssthresh to propagate into the prior_ssthresh
since FRTO declares all such RTOs spurious at once or none of them. In
treating of ssthresh, we mimic what tcp_enter_loss() does.
The previous state (in fr
Retransmission counter assumptions are to be changed. Forcing
reason to do this exist: Using sysctl in check would be racy
as soon as FRTO starts to ignore some ACKs (doing that in the
following patches). Userspace may disable it at any moment
giving nice oops if timing is right. frto_counter would
Moved comments out from the body of process_frto() to the head
(preferred way; see Documentation/CodingStyle). Bonus: it's much
easier to read in this compacted form.
FRTO algorithm and implementation is described in greater detail.
For interested reader, more information is available in RFC4138.
Hi,
Here is a set of patches that fix most of the flaws the current FRTO
implementation (specified in RFC4138) has, besides that, the last two
patches add SACK-enhanced FRTO (not enabled unless frto sysctl is set
to 2, which allows using of the basic version also with SACK). There
are some depenci
FRTO was slightly too brave... Should only clear
TCPCB_SACKED_RETRANS bit.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1a14191..b21e232 100644
FRTO spurious RTO detection algorithm (RFC4138) does not include response
to a detected spurious RTO but can use different response algorithms.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
dif
"Michael K. Edwards" <[EMAIL PROTECTED]> writes:
> A better data structure for RCU, even with a fixed key space, is
> probably a splay tree. Much less vulnerable to cache eviction DDoS
> than a hash, because the hot connections get rotated up into non-leaf
> layers and get traversed enough to kee
Eric Dumazet <[EMAIL PROTECTED]> writes:
>
> So are you speaking of one memory cache miss per lookup ?
Actually two: if the trie'ing allows RCUing you would save
the spinlock cache line too. This would increase the
break-even budget for the trie.
> If not, you loose.
It all depends on if the h
The patch.
Angelo P. Castellani ha scritto:
From: Angelo P. Castellani <[EMAIL PROTECTED]>
YeAH-TCP is a sender-side high-speed enabled TCP congestion control
algorithm, which uses a mixed loss/delay approach to compute the
congestion window. It's design goals target high efficiency, internal,
From: Angelo P. Castellani <[EMAIL PROTECTED]>
YeAH-TCP is a sender-side high-speed enabled TCP congestion control
algorithm, which uses a mixed loss/delay approach to compute the
congestion window. It's design goals target high efficiency, internal,
RTT and Reno fairness, resilience to link loss
From: Angelo P. Castellani <[EMAIL PROTECTED]>
YeAH-TCP is a sender-side high-speed enabled TCP congestion control
algorithm, which uses a mixed loss/delay approach to compute the
congestion window. It's design goals target high efficiency, internal,
RTT and Reno fairness, resilience to link l
Forgot the patch..
Angelo P. Castellani ha scritto:
From: Angelo P. Castellani <[EMAIL PROTECTED]>
RFC3742: limited slow start
See http://www.ietf.org/rfc/rfc3742.txt
Signed-off-by: Angelo P. Castellani <[EMAIL PROTECTED]>
---
To allow code reutilization I've added the limited slow start
pr
From: Angelo P. Castellani <[EMAIL PROTECTED]>
RFC3742: limited slow start
See http://www.ietf.org/rfc/rfc3742.txt
Signed-off-by: Angelo P. Castellani <[EMAIL PROTECTED]>
---
To allow code reutilization I've added the limited slow start procedure
as an exported symbol of linux tcp congestion
Greg KH <[EMAIL PROTECTED]> writes:
> We need our own namespace for these devices, and we have it today
> already. Look if you enable CONFIG_SYSFS_DEPRECATED, or on a pre-2.6.19
> machine at what shows up in the pci device directories:
> -r--r--r-- 1 root root 4096 2007-02-18 13:06 vendor
Inte
87 matches
Mail list logo
