* Re: Driver for Rsltek 8139D / Silan SC92031
From: Stephen Hemminger @ 2006-06-02 20:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Daniel Drake, netdev, cantao
In-Reply-To: <20060602132846.2ee6c71a@localhost.localdomain>
On Fri, 2 Jun 2006 13:28:46 -0700
Stephen Hemminger <shemminger@osdl.org> wrote:
> On Fri, 02 Jun 2006 21:16:53 +0100
> Daniel Drake <dsd@gentoo.org> wrote:
>
> > Here's a strange one. Cantao (on CC) bought what he thought was a cheap
> > realtek PCI NIC, it actually turns out it is a Rsltek (yes, Rsltek)
> > 8139D card.
> >
> > It includes an old (2.4/2.5) driver which claims to be for Silan SC92031
> > (attached).
> >
> > The driver has some very obvious similarities with 8139too, however the
> > register layout and usage is quite different.
> >
> > Has anyone got any idea whats going on here? It seems like something
> > based on a realtek chip, but not...
> >
> > Daniel
> >
>
> It certainly is a good driver as is...
NOT
^ permalink raw reply
* Re: [PATCH 2.6.16.18] MSI: Proposed fix for MSI/MSI-X load failure
From: Rajesh Shah @ 2006-06-02 21:55 UTC (permalink / raw)
To: Ravinandan Arakali
Cc: linux-kernel, netdev, leonid.grossman, ananda.raju, rapuru.sriram
In-Reply-To: <Pine.GSO.4.10.10606021518500.9289-100000@guinness>
On Fri, Jun 02, 2006 at 03:21:37PM -0400, Ravinandan Arakali wrote:
>
> Symptoms:
> When a driver is loaded with MSI followed by MSI-X, the load fails indicating
> that the MSI vector is still active. And vice versa.
>
> Suspected rootcause:
> This happens inspite of driver calling free_irq() followed by
> pci_disable_msi/pci_disable_msix. This appears to be a kernel bug
> wherein the pci_disable_msi and pci_disable_msix calls do not
> clear/unpopulate the msi_desc data structure that was populated
> by pci_enable_msi/pci_enable_msix.
>
The current MSI code actually does this deliberately, not by
accident. It's got a lot of complex code to track devices and
vectors and make sure an enable_msi -> disable -> enable sequence
gives a driver the same vector. It also has policies about
reserving vectors based on potential hotplug activity etc.
Frankly, I've never understood the need for such policies, and
am in the process of removing all of them.
> Proposed fix:
> Free the MSI vector in pci_disable_msi and all allocated MSI-X vectors
> in pci_disable_msix.
>
This will break the existing MSI policies. Once you take that away,
a whole lot of additional code and complexity can be removed too.
That's what I'm working on right now, but such a change is likely
too big for -stable.
So, I'm ok with this patch if it actually doesn't break MSI/MSI-X.
Did you try to repeatedly load/unload an MSI capable driver with
this patch? Did you repeatedly try to ifdown/ifup an Ethernet
driver that uses MSI? I'm not in a position to test this today, but
will try it out next week.
thanks,
Rajesh
^ permalink raw reply
* RE: [PATCH 2.6.16.18] MSI: Proposed fix for MSI/MSI-X load failure
From: Ravinandan Arakali @ 2006-06-02 22:05 UTC (permalink / raw)
To: Rajesh Shah
Cc: linux-kernel, netdev, Leonid Grossman, Ananda Raju, Sriram Rapuru
Rajesh,
It's possible that the current behavior is by design but once the driver is loaded with MSI, you need a reboot to be able to load MSI-X. And vice versa. I found this rather restrictive.
I did test the fix multiple times. For eg. multiple load/unload iterations of
MSI followed by multiple load/unload of MSI-X followed by load/unload MSI. That way both transitions(MSI-to-MSI-X and vice versa) are tested.
Thanks,
Ravi
-----Original Message-----
From: Rajesh Shah [mailto:rajesh.shah@intel.com]
Sent: Friday, June 02, 2006 2:55 PM
To: Ravinandan Arakali
Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; Leonid
Grossman; Ananda Raju; Sriram Rapuru
Subject: Re: [PATCH 2.6.16.18] MSI: Proposed fix for MSI/MSI-X load
failure
On Fri, Jun 02, 2006 at 03:21:37PM -0400, Ravinandan Arakali wrote:
>
> Symptoms:
> When a driver is loaded with MSI followed by MSI-X, the load fails indicating
> that the MSI vector is still active. And vice versa.
>
> Suspected rootcause:
> This happens inspite of driver calling free_irq() followed by
> pci_disable_msi/pci_disable_msix. This appears to be a kernel bug
> wherein the pci_disable_msi and pci_disable_msix calls do not
> clear/unpopulate the msi_desc data structure that was populated
> by pci_enable_msi/pci_enable_msix.
>
The current MSI code actually does this deliberately, not by
accident. It's got a lot of complex code to track devices and
vectors and make sure an enable_msi -> disable -> enable sequence
gives a driver the same vector. It also has policies about
reserving vectors based on potential hotplug activity etc.
Frankly, I've never understood the need for such policies, and
am in the process of removing all of them.
> Proposed fix:
> Free the MSI vector in pci_disable_msi and all allocated MSI-X vectors
> in pci_disable_msix.
>
This will break the existing MSI policies. Once you take that away,
a whole lot of additional code and complexity can be removed too.
That's what I'm working on right now, but such a change is likely
too big for -stable.
So, I'm ok with this patch if it actually doesn't break MSI/MSI-X.
Did you try to repeatedly load/unload an MSI capable driver with
this patch? Did you repeatedly try to ifdown/ifup an Ethernet
driver that uses MSI? I'm not in a position to test this today, but
will try it out next week.
thanks,
Rajesh
^ permalink raw reply
* [FIX] e1000: fix irq sharing when running ethtool test
From: Auke Kok @ 2006-06-02 22:19 UTC (permalink / raw)
To: Jeff Garzik; +Cc: NetDev, Jesse Brandeburg, Auke Kok, Kok, Auke
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
New code added in 2.6.17 caused setup_irq to print a warning when
running ethtool -t eth0 offline.
This test marks the request_irq call made by this test as a "probe" to
see if the interrupt is shared or not.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
Jeff,
Because upstream and upstream-fixes have a whitespace conflict in them, I've
prepared two separate git branches to pull from so that a subsequent pull or
merge from upstream-fixes into upstream doesn't resolve into a conflict:
please pull from our git-server:
into upstream:
git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
into upstream-fixes:
git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes
Cheers,
Auke
---
e1000_ethtool.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
[-- Attachment #2: e1000_setup_irq_probe.patch --]
[-- Type: text/x-patch, Size: 1199 bytes --]
e1000: fix ethtool test irq alloc as "probe"
New code added in 2.6.17 caused setup_irq to print a warning when
running ethtool -t eth0 offline.
This test marks the request_irq call made by this test as a "probe"
to see if the interrupt is shared or not.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index ecccca3..d1c705b 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -870,13 +870,16 @@ e1000_intr_test(struct e1000_adapter *ad
*data = 0;
/* Hook up test interrupt handler just for this test */
- if (!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) {
+ if (!request_irq(irq, &e1000_test_intr, SA_PROBEIRQ, netdev->name,
+ netdev)) {
shared_int = FALSE;
} else if (request_irq(irq, &e1000_test_intr, SA_SHIRQ,
netdev->name, netdev)){
*data = 1;
return -1;
}
+ DPRINTK(PROBE,INFO, "testing %s interrupt\n",
+ (shared_int ? "shared" : "unshared"));
/* Disable all the interrupts */
E1000_WRITE_REG(&adapter->hw, IMC, 0xFFFFFFFF);
^ permalink raw reply related
* Re: [FIX] e1000: fix irq sharing when running ethtool test
From: Jeff Garzik @ 2006-06-02 22:22 UTC (permalink / raw)
To: Auke Kok; +Cc: NetDev, Jesse Brandeburg, Kok, Auke
In-Reply-To: <4480B983.50702@intel.com>
On Fri, Jun 02, 2006 at 03:19:47PM -0700, Auke Kok wrote:
> Because upstream and upstream-fixes have a whitespace conflict in them,
> I've prepared two separate git branches to pull from so that a subsequent
> pull or merge from upstream-fixes into upstream doesn't resolve into a
> conflict:
That won't work, because it creates duplicate changesets in the history.
I'll pull the upstream-fixes version, and then merge into #upstream.
Jeff
^ permalink raw reply
* Re: [FIX] e1000: fix irq sharing when running ethtool test
From: Auke Kok @ 2006-06-02 22:32 UTC (permalink / raw)
To: Jeff Garzik; +Cc: NetDev, Jesse Brandeburg, Kok, Auke
In-Reply-To: <20060602222229.GA24528@havoc.gtf.org>
Jeff Garzik wrote:
> On Fri, Jun 02, 2006 at 03:19:47PM -0700, Auke Kok wrote:
>> Because upstream and upstream-fixes have a whitespace conflict in them,
>> I've prepared two separate git branches to pull from so that a subsequent
>> pull or merge from upstream-fixes into upstream doesn't resolve into a
>> conflict:
>
> That won't work, because it creates duplicate changesets in the history.
>
> I'll pull the upstream-fixes version, and then merge into #upstream.
thanks, I wish I had thought of that first!
Auke
^ permalink raw reply
* Re: [Bugme-new] [Bug 6638] New: tg3 output freezes on compaq nc6000
From: Michael Chan @ 2006-06-02 21:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon@kernel-bugs.osdl.org, netdev, Klaus.Reichl
In-Reply-To: <20060602112248.821c9063.akpm@osdl.org>
On Fri, 2006-06-02 at 11:22 -0700, Andrew Morton wrote:
> On Fri, 2 Jun 2006 05:40:51 -0700
> bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=6638
> >
> > Summary: tg3 output freezes on compaq nc6000
> > Kernel Version: 2.6.16.19
> > Status: NEW
> > Severity: normal
> > Owner: jgarzik@pobox.com
> > Submitter: Klaus.Reichl@alcatel.at
> >
> >
> > Most recent kernel where this bug did not occur: none
> > Distribution: Debian Sarge with latest kernel
> > Hardware Environment: compaq nc6000
> > Software Environment:
> > Problem Description:
> > The output engine of the tg3 driver freezes when generating high load.
> >
> > `ifconfig' shows incomming packets, however, outgoing counter is not incremented
> > any more.
> >
Please provide:
1. tg3 probing output during ifconfig up.
2. /proc/interrupts output to see if interrupt counter is increasing
after failure.
3. "ethtool -d eth0 > dump" after the failure.
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: Herbert Xu @ 2006-06-02 23:12 UTC (permalink / raw)
To: David Daney; +Cc: wildfire, netdev
In-Reply-To: <44806926.1050509@avtrex.com>
David Daney <ddaney@avtrex.com> wrote:
>
> There were some discussions about whether it made sense for the kernel
> to support the behavior required by the RFC. Other comments debated the
> wisdom of using a tightly targeted patch specific to the RFC, or whether
> a more general but intrusive solution would be better.
I think we've made it quite clear what needs to be done for it to be
accepted. All that remains is for someone to implement it. If anyone
really cares about this, then please write the code instead of talking
about it.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* TCP Limited slow start
From: Stephen Hemminger @ 2006-06-02 23:13 UTC (permalink / raw)
To: Xiaoliang Wei, John Heffner; +Cc: netdev
Has anyone done an implementation of RFC3742 for Linux? It looks interesting, but
would need some integration with current ABC code.
There was some evidence of a version in old Web100 code, but it's gone now. Was
it deemed a mistake?
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: Anand Kumria @ 2006-06-03 0:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Daney, netdev
In-Reply-To: <E1FmIoI-0007nK-00@gondolin.me.apana.org.au>
Herbert,
On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
> David Daney <ddaney@avtrex.com> wrote:
> >
> > There were some discussions about whether it made sense for the kernel
> > to support the behavior required by the RFC. Other comments debated the
> > wisdom of using a tightly targeted patch specific to the RFC, or whether
> > a more general but intrusive solution would be better.
>
> I think we've made it quite clear what needs to be done for it to be
> accepted. All that remains is for someone to implement it. If anyone
> really cares about this, then please write the code instead of talking
> about it.
Okay, to confirm: you want a patch which looks at the scope value and if
the scope is link-local then we broadcast rather than do a directed ARP?
One I have where IPv6 encodes what address mask is link-local,
I'd like to follow the same style as. Should the kernel also set the
scope on IPv4 addresses like it does for IPv6 ones?
Thanks,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Miller @ 2006-06-03 0:47 UTC (permalink / raw)
To: wildfire; +Cc: herbert, ddaney, netdev
In-Reply-To: <20060603003955.GJ549@progsoc.uts.edu.au>
RFC3927 seem to be an intellectual property mine field, I really don't
see how we can include this in the Linux kernel.
Go to "http://www.ietf.org/ipr", click on "Search the IPR
disclosures", then enter "3927" in the "Enter RFC number" field and
click SEARCH.
^ permalink raw reply
* Re: The AI parameter of tcp_highspeed.c (in 2.6.18)
From: David Miller @ 2006-06-03 0:51 UTC (permalink / raw)
To: shemminger; +Cc: davidwei79, jheffner, netdev
In-Reply-To: <20060602120507.7e1206d8@dxpl.pdx.osdl.net>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 2 Jun 2006 12:05:07 -0700
> Went backed and looked at the RFC. The problem was just a simple
> translation of table to C array (0 based). Added this to the TCP
> testing repository.
Patch applied, thanks a lot.
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Daney @ 2006-06-03 0:55 UTC (permalink / raw)
To: David Miller; +Cc: wildfire, herbert, netdev
In-Reply-To: <20060602.174756.08320251.davem@davemloft.net>
David Miller wrote:
> RFC3927 seem to be an intellectual property mine field, I really don't
> see how we can include this in the Linux kernel.
>
> Go to "http://www.ietf.org/ipr", click on "Search the IPR
> disclosures", then enter "3927" in the "Enter RFC number" field and
> click SEARCH.
RFC3927 may be a mine field, but the only thing that has to be changed
in the kernel to support it is to somehow configure the arp driver to
broadcast unconditionally on certain interfaces. The majority of the
rfc3927 protocol is done by userspace applications, so should *not*
really effect the kernel.
David Daney.
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Daney @ 2006-06-03 0:58 UTC (permalink / raw)
To: Anand Kumria; +Cc: Herbert Xu, netdev
In-Reply-To: <20060603003955.GJ549@progsoc.uts.edu.au>
Anand Kumria wrote:
> Herbert,
>
> On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
>
>>David Daney <ddaney@avtrex.com> wrote:
>>
>>>There were some discussions about whether it made sense for the kernel
>>>to support the behavior required by the RFC. Other comments debated the
>>>wisdom of using a tightly targeted patch specific to the RFC, or whether
>>>a more general but intrusive solution would be better.
>>
>>I think we've made it quite clear what needs to be done for it to be
>>accepted. All that remains is for someone to implement it. If anyone
>>really cares about this, then please write the code instead of talking
>>about it.
>
>
> Okay, to confirm: you want a patch which looks at the scope value and if
> the scope is link-local then we broadcast rather than do a directed ARP?
>
I don't think that was the plan. In an earlier e-mail Herbert Xu said
(and I concur):
------------------------------
I like the idea of allowing user-space to control what addresses cause
broadcasts. However, I'm uncomfortable with overloading existing flags
even though they might appear to fit the bill on the face of it.
People may be using this for completely different reasons (address
selection) and it's not polite to suddenly turn all their ARPs into
broadcasts.
So how about a new address flag? We still have some vacancies there.
------------------------------
The idea was to add a new flag, *not* reuse the scope value.
David Daney
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: David Miller @ 2006-06-03 1:00 UTC (permalink / raw)
To: ddaney; +Cc: wildfire, herbert, netdev
In-Reply-To: <4480DDF5.2080002@avtrex.com>
From: David Daney <ddaney@avtrex.com>
Date: Fri, 02 Jun 2006 17:55:17 -0700
> RFC3927 may be a mine field, but the only thing that has to be changed
> in the kernel to support it is to somehow configure the arp driver to
> broadcast unconditionally on certain interfaces.
Ok, I'd have to see the final patch after Herbert's suggestions
are taken into account.
^ permalink raw reply
* [RFC] TCP limited slow start
From: Stephen Hemminger @ 2006-06-03 1:54 UTC (permalink / raw)
To: David Miller, John Heffner; +Cc: netdev
In-Reply-To: <20060602161312.3cb2ea66@localhost.localdomain>
Rolled my sleeve's up and gave this a try...
This is a implementation of Sally Floyd's Limited Slow Start
for Large Congestion Windows.
Summary from RFC:
Limited Slow-Start introduces a parameter, "max_ssthresh", and
modifies the slow-start mechanism for values of the congestion window
where "cwnd" is greater than "max_ssthresh". That is, during Slow-
Start, when
cwnd <= max_ssthresh,
cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every
arriving ACK (acknowledgement) during slow-start, as is always the
case. During Limited Slow-Start, when
max_ssthresh < cwnd <= ssthresh,
the invariant is maintained so that the congestion window is
increased during slow-start by at most max_ssthresh/2 MSS per round-
trip time. This is done as follows:
For each arriving ACK in slow-start:
If (cwnd <= max_ssthresh)
cwnd += MSS;
else
K = int(cwnd/(0.5 max_ssthresh));
cwnd += int(MSS/K);
Thus, during Limited Slow-Start the window is increased by 1/K MSS
for each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead
of by 1 MSS as in standard slow-start [RFC2581].
---
Documentation/networking/ip-sysctl.txt | 8 +++++-
include/linux/sysctl.h | 1 +
include/net/tcp.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 8 ++++++
net/ipv4/tcp_cong.c | 46 ++++++++++++++++++++------------
net/ipv4/tcp_input.c | 1 +
6 files changed, 47 insertions(+), 18 deletions(-)
0884f45c9f21c50dd9117b2fc02bf5436be3c3bf
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f12007b..9869298 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -103,9 +103,15 @@ TCP variables:
tcp_abc - INTEGER
Controls Appropriate Byte Count defined in RFC3465. If set to
- 0 then does congestion avoid once per ack. 1 is conservative
+ 0 then does congestion avoid once per ack. 1 (default) is conservative
value, and 2 is more agressive.
+tcp_limited_ssthresh - INTEGER
+ Controls the increase of the congestion window during slow start as
+ defined in RFC3742. The purpose is to slow the growth of the congestion
+ window on high delay networks where agressive growth can cause losses
+ of 1000's of packets. Default is 100 packets.
+
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 76eaeff..a455165 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -403,6 +403,7 @@ enum
NET_TCP_MTU_PROBING=113,
NET_TCP_BASE_MSS=114,
NET_IPV4_TCP_WORKAROUND_SIGNED_WINDOWS=115,
+ NET_TCP_LIMITED_SSTHRESH=116,
};
enum {
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 575636f..3a14861 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -225,6 +225,7 @@ extern int sysctl_tcp_abc;
extern int sysctl_tcp_mtu_probing;
extern int sysctl_tcp_base_mss;
extern int sysctl_tcp_workaround_signed_windows;
+extern int sysctl_tcp_limited_ssthresh;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 6b6c3ad..d1358d3 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -688,6 +688,14 @@ #endif
.mode = 0644,
.proc_handler = &proc_dointvec
},
+ {
+ .ctl_name = NET_TCP_LIMITED_SSTHRESH,
+ .procname = "tcp_max_ssthresh",
+ .data = &sysctl_tcp_limited_ssthresh,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index 857eefc..a27c792 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -180,25 +180,37 @@ int tcp_set_congestion_control(struct so
*/
void tcp_slow_start(struct tcp_sock *tp)
{
- if (sysctl_tcp_abc) {
- /* RFC3465: Slow Start
- * TCP sender SHOULD increase cwnd by the number of
- * previously unacknowledged bytes ACKed by each incoming
- * acknowledgment, provided the increase is not more than L
- */
- if (tp->bytes_acked < tp->mss_cache)
- return;
-
- /* We MAY increase by 2 if discovered delayed ack */
- if (sysctl_tcp_abc > 1 && tp->bytes_acked > 2*tp->mss_cache) {
- if (tp->snd_cwnd < tp->snd_cwnd_clamp)
- tp->snd_cwnd++;
- }
+ /* RFC3465: Apprpriate Byte Coute Slow Start
+ * TCP sender SHOULD increase cwnd by the number of
+ * previously unacknowledged bytes ACKed by each incoming
+ * acknowledgment, provided the increase is not more than L
+ */
+ if (sysctl_tcp_abc && tp->bytes_acked < tp->mss_cache)
+ return;
+
+ /* RFC3742: limited slow start
+ * the window is increased by 1/K MSS for each arriving ACK,
+ * for K = int(cwnd/(0.5 max_ssthresh))
+ */
+ if (sysctl_tcp_limited_ssthresh
+ && tp->snd_cwnd > sysctl_tcp_limited_ssthresh) {
+ u32 k = max(tp->snd_cwnd / (sysctl_tcp_limited_ssthresh >> 1), 1U);
+ if (++tp->snd_cwnd_cnt >= k) {
+ if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
+ tp->snd_cwnd_cnt = 0;
+ }
+ } else {
+ /* ABC: We MAY increase by 2 if discovered delayed ack */
+ if (sysctl_tcp_abc > 1
+ && tp->bytes_acked > 2*tp->mss_cache
+ && tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
+
+ if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
}
tp->bytes_acked = 0;
-
- if (tp->snd_cwnd < tp->snd_cwnd_clamp)
- tp->snd_cwnd++;
}
EXPORT_SYMBOL_GPL(tcp_slow_start);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 718d0f2..80dd5e4 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -90,6 +90,7 @@ int sysctl_tcp_nometrics_save;
int sysctl_tcp_moderate_rcvbuf = 1;
int sysctl_tcp_abc = 1;
+int sysctl_tcp_limited_ssthresh = 100;
#define FLAG_DATA 0x01 /* Incoming frame contained data. */
#define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */
--
1.3.3
^ permalink raw reply related
* Re: [PATCH 2.6.16.18] MSI: Proposed fix for MSI/MSI-X load failure
From: Paul Mackerras @ 2006-06-03 2:09 UTC (permalink / raw)
To: Rajesh Shah
Cc: Ravinandan Arakali, linux-kernel, netdev, leonid.grossman,
ananda.raju, rapuru.sriram
In-Reply-To: <20060602145512.A13024@unix-os.sc.intel.com>
Rajesh Shah writes:
> The current MSI code actually does this deliberately, not by
> accident. It's got a lot of complex code to track devices and
> vectors and make sure an enable_msi -> disable -> enable sequence
> gives a driver the same vector. It also has policies about
> reserving vectors based on potential hotplug activity etc.
> Frankly, I've never understood the need for such policies, and
> am in the process of removing all of them.
Good. We will not be able to support a policy of giving the driver
the same vector across an enable_msi/disable/enable sequence on IBM
System p machines (64-bit PowerPC), because the firmware controls the
MSI allocation, and it doesn't give us the necessary guarantees.
Paul.
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: Anand Kumria @ 2006-06-03 2:50 UTC (permalink / raw)
To: David Daney; +Cc: Herbert Xu, netdev
In-Reply-To: <4480DEB3.2060806@avtrex.com>
On Fri, Jun 02, 2006 at 05:58:27PM -0700, David Daney wrote:
> Anand Kumria wrote:
> >Herbert,
> >
> >On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote:
> >
> >>David Daney <ddaney@avtrex.com> wrote:
> >>
> >>>There were some discussions about whether it made sense for the kernel
> >>>to support the behavior required by the RFC. Other comments debated the
> >>>wisdom of using a tightly targeted patch specific to the RFC, or whether
> >>>a more general but intrusive solution would be better.
> >>
> >>I think we've made it quite clear what needs to be done for it to be
> >>accepted. All that remains is for someone to implement it. If anyone
> >>really cares about this, then please write the code instead of talking
> >>about it.
> >
> >
> >Okay, to confirm: you want a patch which looks at the scope value and if
> >the scope is link-local then we broadcast rather than do a directed ARP?
> >
>
> I don't think that was the plan. In an earlier e-mail Herbert Xu said
> (and I concur):
>
> ------------------------------
> I like the idea of allowing user-space to control what addresses cause
> broadcasts. However, I'm uncomfortable with overloading existing flags
> even though they might appear to fit the bill on the face of it.
>
[...]
Sorry, I can't find any email with any of those words in it by Herbert.
Could you tell me the message-id, so I can read some of the surrounding
context?
>
> The idea was to add a new flag, *not* reuse the scope value.
>
I guess it would be something set during RTM_NEWADDR (and returned by
RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int;
defaulting to 1. When set to 0, generate a broadcast ARP for the
address.
Thanks,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* link-local address via ifconfig
From: Anand Kumria @ 2006-06-03 2:57 UTC (permalink / raw)
To: netdev
Hi,
There are plenty of people who still use ifconfig to list the addresses
assigned to their network interfaces (I know, ifconfig is broken) and
who then parse the output.
However the kernel puts link-local scoped address first if the address
list of an interface, so an interface like:
eve:[~]% ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:12:f0:03:d9:e7 brd ff:ff:ff:ff:ff:ff
inet 169.254.182.108/16 brd 169.254.255.255 scope link wlan0
inet 192.168.2.2/24 brd 192.168.2.255 scope global wlan0
inet6 fe80::212:f0ff:fe03:d9e7/64 scope link
valid_lft forever preferred_lft forever
appears as:
eve:[~]% ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:12:F0:03:D9:E7
inet addr:169.254.182.108 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::212:f0ff:fe03:d9e7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[... elided ...]
Is there any reason to put the link-local address first in the list?
I've had a number of bugreports (or outright panic attacks) where the
problem turned out to be that ifconfig was reporting the link-local
address first, rather than the global/site one.
Thanks,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* Re: RFC3927 ARP patch status?
From: Herbert Xu @ 2006-06-03 4:52 UTC (permalink / raw)
To: Anand Kumria; +Cc: David Daney, netdev
In-Reply-To: <20060603025001.GK549@progsoc.uts.edu.au>
On Sat, Jun 03, 2006 at 12:50:02PM +1000, Anand Kumria wrote:
>
> I guess it would be something set during RTM_NEWADDR (and returned by
> RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int;
> defaulting to 1. When set to 0, generate a broadcast ARP for the
> address.
Address flags start with IFA_F and are in ifa_flags.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: link-local address via ifconfig
From: Herbert Xu @ 2006-06-03 4:55 UTC (permalink / raw)
To: Anand Kumria; +Cc: netdev
In-Reply-To: <20060603025743.GL549@progsoc.uts.edu.au>
Anand Kumria <wildfire@progsoc.uts.edu.au> wrote:
>
> There are plenty of people who still use ifconfig to list the addresses
> assigned to their network interfaces (I know, ifconfig is broken) and
> who then parse the output.
If people insist on using hammers on screws, the answer is not to improve
the hammer.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* driver for pptp
From: xeb @ 2006-06-03 7:06 UTC (permalink / raw)
To: netdev
Hello.
I have developed the driver for Point-to-Point Tunneling Protocol (PPTP).
This driver works in pair with plugin for pppd.
It is enough to use pppd's plugin for start of the client.
Also there is a server (based on pptpd) which uses this driver.
By results of my testing the speed of transfer has increased on >50% and cpu usage has decreased on >50% in comparison with original pptpd and pptpclient.
I have published the project on http://accel-pptp.sourceforge.net/
There is more then 65 downloads but no any bug report (and no any positive result report).
I think the driver still requires testing.
Hope this driver will go to a kernel tree and will make linux more productive.
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Stefan Rompf @ 2006-06-03 8:45 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Francois Romieu, netdev
In-Reply-To: <200606021630.34544.IvDoorn@gmail.com>
Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
> > Or actually, I don't think the radiobtn/ won't be actually needed as
> > prefix. The name passed to the radiobtn driver by the driver should be
> > sufficient.
>
> Updated version,
>
> Signed-off-by Ivo van Doorn <IvDoorn@gmail.com>
I don't like the patch in it's current form. Many notebooks have a number of
additional keys that need to be queried/polled using the same interface, but
just one button is to control the radio, the rest are multimedia keys that
just need to be forwarded to userspace. Or maybe a bluetooth key.
Some systems require suspend/resume support, others remember state of the
wireless button automatically. For a perfect example, look at
drivers/input/misc/wistron_btns.c.
So you should create an "extra laptop buttons" interface. Though it may be
hard to assure that this generalization layer between input system and
hardware is still a win for the driver developer.
Stefan
^ permalink raw reply
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-06-03 9:54 UTC (permalink / raw)
To: bugme-daemon; +Cc: David S. Miller, netdev
In-Reply-To: <200605271731.k4RHVJTb018158@fire-2.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On Sat, May 27, 2006 at 10:31:19AM -0700, bugme-daemon@bugzilla.kernel.org wrote:
>
> Ok, see the attachment (ALL.txt.gz) for the tcpdump output. If you would like
> the hexdump or more, please give the tcpdump filter rule to me.
Thanks a lot. So it wasn't as uncommon as I thought. In fact, partial
odd acks like yours happen all the time as part of FIN handling. So this
is something that we want to address.
BTW, we should also fix arch/alpha/kernel/io.c to not crash on
unaligned data. Most other common architectures will grin and
bear it.
[TCP]: Avoid skb_pull if possible when trimming head
Trimming the head of an skb by calling skb_pull can cause the packet
to become unaligned if the length pulled is odd. Since the length is
entirely arbitrary for a FIN packet carrying data, this is actually
quite common.
Unaligned data is not the end of the world, but we should avoid it if
it's easily done. In this case it is trivial. Since we're discarding
all of the head data it doesn't matter whether we move skb->data forward
or back.
However, it is still possible to have unaligned skb->data in general.
So network drivers should be prepared to handle it instead of crashing.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: tcp-trim-head.patch --]
[-- Type: text/plain, Size: 435 bytes --]
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 743016b..bd7c89b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -676,7 +676,7 @@ int tcp_trim_head(struct sock *sk, struc
pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
return -ENOMEM;
- if (len <= skb_headlen(skb)) {
+ if (len < skb_headlen(skb)) {
__skb_pull(skb, len);
} else {
if (__pskb_trim_head(skb, len-skb_headlen(skb)) == NULL)
^ permalink raw reply related
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-03 10:51 UTC (permalink / raw)
To: herbert; +Cc: bugme-daemon, davem, netdev, yoshfuji
In-Reply-To: <20060603095442.GA373@gondor.apana.org.au>
In article <20060603095442.GA373@gondor.apana.org.au> (at Sat, 3 Jun 2006 19:54:42 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> [TCP]: Avoid skb_pull if possible when trimming head
>
> Trimming the head of an skb by calling skb_pull can cause the packet
> to become unaligned if the length pulled is odd. Since the length is
> entirely arbitrary for a FIN packet carrying data, this is actually
> quite common.
I think that people will start thinking why we cannot
skb_pull(skb, len) if skb_headlen(skb) == len; some comment needed...
--yoshfuji
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox