Quoting r. David S. Miller [EMAIL PROTECTED]:
well, there are stacks which do stretch acks (after a fashion) that
make sure when they see packet loss to do the right thing wrt sending
enough acks to allow cwnds to open again in a timely fashion.
Once a loss happens, it's too late to
John W. Linville wrote:
The following changes since commit dd288e7d75b9041f79fecae77d61cfa345da7266:
John W. Linville:
Merge branch 'upstream-fixes'
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
pulled
-
To
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Mon, 20 Mar 2006 11:06:29 +0200
Is it the case then that this requirement is less essential on
networks such as IP over InfiniBand, which are very low latency
and essencially lossless (with explicit congestion contifications
in hardware)?
You
I discovered that there is problem with 2.6.15 and 2.6.16 kernels -
network interface (e100) comes up without link-local address. Both e100
and IPv6 are compiled into kernel. From dmesg:
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
There
Quoting r. David S. Miller [EMAIL PROTECTED]:
The path an SKB can take is opaque and unknown until the very last
moment it is actually given to the device transmit function.
Why, I was proposing looking at dst cache. If that's NULL, well,
we won't stretch ACKs. Worst case we apply the wrong
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Mon, 20 Mar 2006 12:22:34 +0200
Quoting r. David S. Miller [EMAIL PROTECTED]:
The path an SKB can take is opaque and unknown until the very last
moment it is actually given to the device transmit function.
Why, I was proposing looking at
[just sent upstream; patch snipped due to size]
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
Documentation/DocBook/sis900.tmpl | 585 --
Documentation/networking/sis900.txt
On Mon, Mar 20, 2006 at 12:47:03PM +0100, Arjan van de Ven wrote:
I disagree with Linux changing it's behavior. It would be great to
turn off congestion control completely over local gigabit networks,
but that isn't determinable in any way, so we don't do that.
Interesting. Would
On Mon, 2006-03-20 at 12:49 +0100, Lennert Buytenhek wrote:
On Mon, Mar 20, 2006 at 12:47:03PM +0100, Arjan van de Ven wrote:
I disagree with Linux changing it's behavior. It would be great to
turn off congestion control completely over local gigabit networks,
but that isn't
Quoting r. Lennert Buytenhek [EMAIL PROTECTED]:
I disagree with Linux changing it's behavior. It would be great to
turn off congestion control completely over local gigabit networks,
but that isn't determinable in any way, so we don't do that.
Interesting. Would it make sense
Quoting Arjan van de Ven [EMAIL PROTECTED]:
I read it as if he was proposing to have a sysctl knob to turn off
TCP congestion control completely (which has so many issues it's not
even funny.)
owww that's so bad I didn't even consider that
No, I think that comment was taken out of thread
On Mon, 2006-20-03 at 14:46 +1000, Russell Stuart wrote:
On Sun, 2006-03-19 at 11:32 -0500, jamal wrote:
From what I can see, you are not testing a real data
set here. Is that the case?
Its a worst case scenario test setup - You lookup at all possible data
values.
Normally it is the best
On Mon, Mar 20, 2006 at 02:04:07PM +0200, Michael S. Tsirkin wrote:
does not stretch ACKs anymore. RFC 2581 does mention that it might be OK to
stretch ACKs after careful consideration, and we are seeing that it helps
IP over InfiniBand, so recent Linux kernels perform worse in that respect.
Anand Kumria wrote:
Hi,
I'm writing a program which receives ARP packets and have noticed that
broadcast ARP packets seem to come in with the destination hardware
address set as all zeros.
long, Long, LONG ago, all-zeros was considered broadcast. however,
long, Long ago, that was switched
The XFRM code base looks like it needs a relatively intrusive change to
support protocols like SCTP correctly. The problem is that security
policies are cached on the socket level, where SCTP not only uses
multiple addresses per association, but multiple associations per socket.
I believe
Hi Rick,
On Mon, Mar 20, 2006 at 10:27:07AM -0800, Rick Jones wrote:
Anand Kumria wrote:
Hi,
I'm writing a program which receives ARP packets and have noticed that
broadcast ARP packets seem to come in with the destination hardware
address set as all zeros.
long, Long, LONG ago,
And there you have it - four separate sends for logically associated
data, when there should have been just the one sendmsg or writev call.
Given the sizes involved, that is roughly three to four times as much
CPU consumed to send that data is should have been - for small
packets you can
Stephen,
Thank you for taking the time to review my driver. The feedback was
great. I will endeavor to bring it up to an A+. Please see my comments
below.
-Original Message-
From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 1:35 PM
To: Ron Mercer
Cc:
Rick Jones wrote:
It _would_ be very interesting to see if disabling tcp_abc does
workaround the problem.
Yes it does, we tried that first. Then we reenabled tcp_abc and
increased the toolkit keep_alive. Either method works around the issue
from our point of view.
---
John
-
To
On Mon, 20 Mar 2006 11:07:34 -0800
Ron Mercer [EMAIL PROTECTED] wrote:
Stephen,
Thank you for taking the time to review my driver. The feedback was
great. I will endeavor to bring it up to an A+. Please see my comments
below.
* Do nvram via ethtool
I am not sure what you mean here.
On Mon, 20 Mar 2006 11:56:32 -0800
Skunk Worx [EMAIL PROTECTED] wrote:
Rick Jones wrote:
It _would_ be very interesting to see if disabling tcp_abc does
workaround the problem.
Yes it does, we tried that first. Then we reenabled tcp_abc and
increased the toolkit keep_alive. Either
* Chris Wright ([EMAIL PROTECTED]) wrote:
* Ingo Oeser ([EMAIL PROTECTED]) wrote:
Hi Chris,
Andrew Morton wrote:
Ingo Oeser [EMAIL PROTECTED] wrote:
-int scm_send(struct socket *sock, struct msghdr *msg, struct
scm_cookie *scm)
-{
- struct task_struct *p =
Chris Wright [EMAIL PROTECTED] wrote:
* Chris Wright ([EMAIL PROTECTED]) wrote:
* Ingo Oeser ([EMAIL PROTECTED]) wrote:
Hi Chris,
Andrew Morton wrote:
Ingo Oeser [EMAIL PROTECTED] wrote:
-int scm_send(struct socket *sock, struct msghdr *msg, struct
scm_cookie
* Andrew Morton ([EMAIL PROTECTED]) wrote:
Chris Wright [EMAIL PROTECTED] wrote:
Catherine, the security_sid_to_context() is a raw SELinux function which
crept into core code and should not have been there. The fallout fixes
included conditionally exporting security_sid_to_context, and
Boards with multiple PHYs were not being handled properly by the pcnet32
driver. This patch by Thomas Bogendoerfer with changes by me will allow
Allied Telesyn 2700FTX and 2701FTX boards to use either the copper or
the fiber interfaces. It has been tested on ia32 and ppc64 hardware.
Philippe
On Mon, 2006-03-20 at 10:00 -0500, jamal wrote:
I have to say i am scratching my head - now that i was forced to run the
tests - to see if there is infact a scenario where you could show 2.4 to
be better...
So that is the underlying reason you are resisting -
you just can't see that it could
The hardware has additional error trap interrupt bits. I have never seen
them trigger, but if they do, it looks like this might be useful.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Index: sky2-2.6.17/drivers/net/sky2.c
The Yukon EC/rev0 (A1) chipset requires a bunch of workarounds. I copied these
from sk98lin. But since they never got tested and add more cruft to the code;
any attempt at using driver as is on this version will probably fail.
It looks like this was a early engineering sample chip revision, if
Set version to 1.1
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-14 09:39:38.0 -0800
+++ sky2-2.6.17/drivers/net/sky2.c 2006-03-20 11:05:57.0 -0800
@@ -51,7 +51,7 @@
#include sky2.h
#define DRV_NAME sky2
Redo the interupt handling of sky2 driver based on the IRQ mangement
documentation. All interrupts are handled by the device0 NAPI poll
routine.
Don't need to adjust interrupt mask in IRQ context, done only when
changing device under RTNL. Therefore don't need hwlock anymore.
Signed-off-by:
Small whitespace fixes.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-07 14:05:53.0 -0800
+++ sky2-2.6.17/drivers/net/sky2.c 2006-03-07 14:21:17.0 -0800
@@ -852,7 +852,7 @@
if (!netif_running(dev))
Add MSI support to sky2 driver.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-20 14:32:43.0 -0800
+++ sky2-2.6.17/drivers/net/sky2.c 2006-03-20 14:33:07.0 -0800
@@ -92,6 +92,10 @@
module_param(copybreak, int, 0);
This patch decodes state and revovers from any races in the transmit
timeout and NAPI logic. It should never trigger, but if it does then
do the right thing.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-20 14:33:26.0 -0800
+++
New version of sky2 for 2.6.17. The big change is using
IRQ control registers properly to avoid races in NAPI. This
also means MSI now works.
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Remove wake on lan support for now. It doesn't work right, and I
don't have a machine with working suspend/resume to test or fix it.
It will be re-enabled later.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-14 09:39:38.0 -0800
+++
From: Chris Wright [EMAIL PROTECTED]
Date: Mon, 20 Mar 2006 13:36:36 -0800
The point of Catherine's original patch was to make sure there's always
a security identifier associated with AF_UNIX messages. So receiver
can always check it (same as having credentials even w/out sender
control
* David S. Miller ([EMAIL PROTECTED]) wrote:
From: Chris Wright [EMAIL PROTECTED]
Date: Mon, 20 Mar 2006 13:36:36 -0800
The point of Catherine's original patch was to make sure there's always
a security identifier associated with AF_UNIX messages. So receiver
can always check it (same
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Mon, 20 Mar 2006 10:09:42 -0500
Wouldn't it make sense to strech the ACK when the previous ACK is still in
the TX queue of the device? I know that sort of behaviour was always an
issue on modem links where you don't want to send out redundant
On Mon, 20 Mar 2006, David S. Miller wrote:
I'm seriously considering backing out Catherine's AF_UNIX patch from
the net-2.6.17 tree before submitting it to Linus later today so that
none of this crap goes in right now.
I believe Catherine is away this week, so it's probably best to drop the
hello,
the attached patch fixes a problem I had when running 2 different
Au15xx-based boards (Au1500 and Au1550) in bridging mode under high load.
au1000_tx_timeout() would reset the device for which it was called, but
promiscuous mode was not re-established.
tested under 2.6.14, 2.6.16-rc6
From: James Morris [EMAIL PROTECTED]
Date: Mon, 20 Mar 2006 19:37:51 -0500 (EST)
I believe Catherine is away this week, so it's probably best to drop the
code and wait till she gets back and we can get it 100% right.
Ok, agreed.
Sorry, this is my fault, I should have caught this problem.
Having given someone the answer of 2.6.14 has a 'full fixed' TSO (from
the standpoint of slow start and remaining on for a connection after
retransmission they have shot back with Do you know the fix ID's so I
can see if distro foo has incorporated them?
Could someone give me a gentle tap
On Mon, 20 Mar 2006 19:30:17 -0800
Randy.Dunlap [EMAIL PROTECTED] wrote:
in Documentation/networking/TODO, the Jamal netdev Rx polling API change
is done, right? (NAPI)
Are any of the others done?
Should this TODO file be removed or updated or reference
43 matches
Mail list logo
