Bill Fink wrote:
If the receive direction uses a different GigE NIC that's part of the
same quad-GigE, all is fine:
[EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta
-Irx -r -w2m 192.168.5.79
tx: 1186.5051 MB / 10.05 sec = 990.2250 Mbps 12 %TX 13 %RX 0 retrans
rx:
Jeff Garzik wrote:
Kok, Auke wrote:
David Acker wrote:
What is the status of this patch?
Jeff merged it in netdev-2.6#upstream so it is queued for 2.6.25.
However, we could consider pushing this patch to 2.6.24 since it's a
valid fix.
Andrew has also been carrying this patch in -mm
What is the status of this patch? Is there anything folks would like me to do in order to move it forward? As an FYI,
my company has been using this patch since I posted it and so far we have not had any problems with it.
-Ack
Auke Kok wrote:
From: David Acker <[EMAIL PROTECTED]>
move on to the next buffer and skip this one. If it
sees the size set but the el-bit still set, it will complete that buffer
and then RNR interrupt and wait.
This is a patch for 2.6.24-rc1.
Signed-off-by: David Acker <[EMAIL PROTECTED]>
---
This version is based on the simpler patch I did
.
Agreed, there is still a receive unit hang in the last version that I got from
David Acker.
Auke
Yes, I have not had much time to work on it. :-(
In testing, I was also able to get crashes which I believe are from receive skb
corruption.
It doesn't ever appear in our normal use te
James Chapman wrote:
David Acker wrote:
Jeff Garzik wrote:
pktgen outputs for the various cases modified/unmodified[/others?]
would be nice, if you have a spot of time.
Jeff
I am not familiar with pktgen but I seem to have it working for a
simple test.
I edited the 1-1 example from
Jeff Garzik wrote:
David Acker wrote:
Let me know if there is any other information I can provide you. I
will look through the code to see what could be going on with your
machine. I will also look into reproducing these results with a newer
kernel. This may be tricky since compulab&#
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru too much, but
I haven't had time to lo
ed to prevent two
packets in a row being marked while the receiver is running to avoid running
in lockstep with the hardware and thereby limiting the required lookahead.
This is a patch for 2.6.23-rc4.
Signed-off-by: David Acker <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc4/drivers/net/
Kok, Auke wrote:
Milton Miller wrote:
On Jun 5, 2007, at 8:34 AM, David Acker wrote:
David, Milton,
This was the last communication on-topic for the proposed changes to fix
e100 on ARM. We're holding our breath here waiting for more, and would
love to hear that this issue and fixes h
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
We need to make sure that now that we're getting closer to 2.6.22 we don't
end up killing e100 in it. Should we drop the current fixes in it to be on
the safe side and aim for 2.6.23? I would hate to see an untested c
Milton Miller wrote:
On Jun 1, 2007, at 3:45 PM, David Acker wrote:
Ok, I took a stab at coding and testing these ideas. Below is a patch
against 2.6.22-rc3.
Let me know what you think.
I think you got most of the ideas. As Auke noted, your coding style is
showing again. And your
nd skip this one. If it sees
the size set but the el-bit still set, it will complete that buffer
and then RNR interrupt and wait.
Signed-off-by: David Acker <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc3/drivers/net/e100.c.orig2007-06-01 16:13:16.0
-0400
+++ linux-2.6.22-
Ok, I finally got some time to code this out and study it and Ihave some
questions.
Milton Miller wrote:
We add two flags to struct rx: one says this packet is EL, and one says
it is or was size 0. We create a function, find_mark_el(struct nic,
is_running) that is called after initial alloc a
Milton Miller wrote:
Ok here's my just-before-dinner brainstorming, as relayed after dinner:
We add two flags to struct rx: one says this packet is EL, and one says
it is or was size 0. We create a function, find_mark_el(struct nic,
is_running) that is called after initial alloc and/or after
Milton Miller wrote:
On May 23, 2007, at 4:32 PM, David Acker wrote:
Milton Miller wrote:
My current reading of the manual is that the C bit will not be
set on an RFD that is size 0. It goes on to processes EL and
S, and decides to stop and interrupt RNR or suspend, or just
go to the next
Milton Miller wrote:
I agree with this part of the approach. I just think we need
a bit more work on the "what to do when we are ready for
hardware to not stop" part.
Agreed.
The sync is required to push both cache lines, but there is no
ordering guarantee. This probably is why you saw size
Milton Miller wrote:
Proceeding with the review:
Coding style:
(1) if body on seperate line.
(2) space after if before (
(3) The other enums in this driver are not ALL_CAPS
(4) This driver doesn't do CONSTANT != value but value != enum
(see nic->mac for examples)
I sent Milton my copy of t
complete that one in error. If it sees
the size set but the el-bit still set, it will complete that buffer
and then RNR interrupt and wait.
Signed-off-by: David Acker <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc1/drivers/net/e100.c.orig2007-05-18 13:08:01.0
-0400
+++ linux-2.6.
Kok, Auke wrote:
David Acker wrote:
David Acker wrote:
Done. Below is a patch against 2.6.22-rc1. It combines removing the
s-bit patch and applying the patch I previously sent.
Oops. I missed one state in that patch. Since the el-bit buffer will
normally not complete due to a zero size
David Acker wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
I'm expecting at least a reply from Milton as the patch was sent to
him. I haven't yet tested it but will certainly do so. At first glance
i
ware sees the el-bit cleared without the size set, it will
move on to the next buffer and complete that one in error. If it sees
the size set but the el-bit still set, it will complete that buffer
and then RNR interrupt and wait.
Signed-off-by: David Acker <[EMAIL PROTECTED]>
---
--- linux-2
ill complete that buffer
and then RNR interrupt and wait.
Signed-off-by: David Acker <[EMAIL PROTECTED]>
---
--- linux-2.6.21.1/drivers/net/e100.c.orig 2007-05-11 11:27:11.0
-0400
+++ linux-2.6.21.1/drivers/net/e100.c 2007-05-11 11:39:06.0 -0400
@@ -1781,13 +178
Lennert Buytenhek wrote:
The people who need a LE network driver can use Christian's driver,
as Christian's driver works in LE just fine. The people who care
about LE support can add LE support to the driver that Krzysztof wrote.
I don't think that not supporting LE is a reason not to merge
Krz
Milton Miller wrote:
While this will help the problem with the cache-incoherent DMA systems
not running, it guarantees the hardware will stop every
packets and wait for the cpu to respond to an interrupt. It would seem
that this will lead to packet drops.
Well, in NAPI mode, we the CPU may
David Acker wrote:
So far my testing has shown both the original and the new version of the
S-bit patch work in that no corruption seemed to occur over long term
runs.
I spoke too soon. Further testing has not gone well. If I use the
default settings for CPU saver and drop the receive pool
David Acker wrote:
Milton Miller wrote:
In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
talks about emulating another driver by setting addtional bits and
the being unable to test when submitted. Seeing the & operator to
set more bits made me suspicious, and indeed the
Milton Miller wrote:
In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
talks about emulating another driver by setting addtional bits and
the being unable to test when submitted. Seeing the & operator to
set more bits made me suspicious, and indeed the bits are defined
in posit
Lennart Sorensen wrote:
Well the IT8152G+PXA255 combination used on the SBC we tried a couple of
years ago did not work. The PCI bus had errors and the SBC maker gave
up trying to fix it. We switched to a Geode SC1200 based board instead
which works fine PCI wise.
I don't think this is it.
Lennart Sorensen wrote:
Which PCI host controller are you using with the PXA255? We tried using
a PXA255 based system with a PCI controller a couple of years ago and
have to change to a different cpu in the end due to the PCI controller
simply not being valid PCI. The PXA255 wasn't designed for
Kok, Auke wrote:
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp235
Rick Jones wrote:
With mii-tool we can do the command below and work with a half duplex
hub and a full duplex switch.
mii-tool -A 10baseT-FD,10baseT-HD eth0
Why, and how often, is that really necessary?
rick jones
Take a wifi router with only 802.11b radios and ethernet chips that do
not
Stephen Hemminger wrote:
On Tue, 26 Sep 2006 17:55:34 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
The mii-tool utility seems to be abandoned and unmaintained?
Here is a version that does standard 1000baseT support.
http://developer.osdl.org/shemminger/prototy
David S. Miller wrote:
From: David Acker <[EMAIL PROTECTED]>
Date: Fri, 14 Apr 2006 09:15:54 -0400
David S. Miller wrote:
> I think this really belongs in a portable header file
> in glibc somewhere.
David, while I can try to work with the glibc folks, I don't understan
David Acker wrote:
From Dave Acker <[EMAIL PROTECTED]>
The purpose is to allow a user space program to use the vlan_ethhdr
structure when directly handling 802.1Q packets. This can be done
by using a raw socket like:
int s = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
This socket
David S. Miller wrote:
From: David Acker <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 14:12:05 -0400
This is a second attempt at a patch for include/linux/if_vlan.h .
Its purpose is to allow a user space program to use the vlan_ethhdr
structure when directly handling 802.1Q packets. Th
ed-off-by: David Acker <[EMAIL PROTECTED]>
This is a third attempt at a patch for include/linux/if_vlan.h .
I am sorry I got the diff wrong on the previous posts; I am a bit new
to linux kernel contributions. This time I believe I fixed the patch
format to match the linux kernel doc.
structure.
-Dave Acker
Signed-off-by: David Acker <[EMAIL PROTECTED]>
--
*** if_vlan.h.orig 2006-03-19 21:11:01.0 -0500
--- if_vlan.h 2006-04-07 13:51:44.0 -0400
***
*** 13,18
--- 13,26
#ifndef _LINUX_IF_V
Ben Greear wrote:
The reason I suggested to not make the size #defines visible is that it
really doesn't help
much. If you are receiving in user space, a more useful number is:
sizeof(vlan_eth_header) + MTU of interface
Depending on the underlying NIC, you may still receive larger packets, so
vlan_ethhdr structure. The sizes are useful
since they let the user space program know how much space is really
needed to receive VLAN packets.
-Dave Acker
Signed-off-by: David Acker <[EMAIL PROTECTED]>
*** if_vlan.h.orig 2006-03-19 21:11:01.0 -0500
--- if_vlan.h 2006
40 matches
Mail list logo
