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 hasn't died off.
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 hasn't
On Jun 6, 2007, at 4:28 AM, Milton Miller wrote:
On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:
Kok, Auke wrote:
Hmm git-revert seems to do the job right. I checked it with git-show
| patch -p1 -R and the results look OK. The two patches on top of
the one we want to revert are unrelated
On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:
Kok, Auke wrote:
Hmm git-revert seems to do the job right. I checked it with git-show
| patch -p1 -R and the results look OK. The two patches on top of the
one we want to revert are unrelated enough to apply (manually it
shows some fuzz, but
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
First, a question especially to Auke and Jeff:
Since this patch both reverts the broken change that is currently in
-rc and creates the fixed driver, I'm not sure I like the subject
stating on ARM, although that is the feature of the rewrite, and was
the intent of merging the previous patch.
On Jun 5, 2007, at 8:34 AM, David Acker wrote:
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
Milton Miller wrote:
First, a question especially to Auke and Jeff:
Since this patch both reverts the broken change that is currently in
-rc and creates the fixed driver, I'm not sure I like the subject
stating on ARM, although that is the feature of the rewrite, and was
the intent of
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
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
On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
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
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 codepath
Milton Miller wrote:
On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
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 Tue, Jun 05, 2007 at 04:33:12PM -0700, Kok, Auke wrote:
Jeff, please `git-revert d52df4a35af569071fda3f4eb08e47cc7023f094` to
revert the following patch for now:
Can you do me one more favor, and write a short paragraph describing why
it is getting reverted, to paste into the commit
Kok, Auke wrote:
Milton Miller wrote:
On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
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
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 mailer again munged
Milton Miller wrote:
Your logic works, this adds some conditional branching but saves a
pointer, not sure which is better. Mine can be used for initializing
without special casing since it will just calculate rx_to_unmark as
rx[n-2] and rx_to_mark as rx[n-2] != rx[n-2]-prev; unmarking a never
David Acker wrote:
Milton Miller wrote:
Your logic works, this adds some conditional branching but saves a
pointer, not sure which is better. Mine can be used for initializing
without special casing since it will just calculate rx_to_unmark as
rx[n-2] and rx_to_mark as rx[n-2] !=
Jeff Garzik wrote:
David Acker wrote:
Milton Miller wrote:
snip
the el flag but we leave the size was 0 bit set. This was we can find
this buffer again later.
If the hardware sees the el-bit cleared without the size set, it will
move on to the next buffer and skip this one. If it sees
On May 29, 2007, at 10:58 AM, David Acker wrote:
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,
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
Some further thoughts ...
On May 24, 2007, at 12:26 AM, 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
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:
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
On May 24, 2007, at 7:51 AM, David Acker wrote:
Milton Miller wrote:
Comments? Questions?
This sounds pretty reasonable. I will take a stab at coding this up
today; I always think better looking at code.
Thanks.
By the way, find_mark_el should probably get passed
the old fill point. The
I tried to remove anything we were in agreement with.
On May 22, 2007, at 5:07 PM, David Acker wrote:
Milton Miller wrote:
Many of the issues you bring have been in the e100 for some time. If
you ignore the s-bit patch, I basically did the the following:
moved the el-bit to before the last
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
Auke Kok pointed out I had left an unfinished thought this
morning ... well, here's a completion, but I will mostly
think about David's latest proposal.
I think I was debating proposing this, then got side
tracked then hit send.
On May 23, 2007, at 9:02 AM, Milton Miller wrote:
What if we
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 packet.
I double checked
On May 21, 2007, at 12:45 PM, Kok, Auke wrote:
Milton Miller wrote:
On May 18, 2007, at 12:11 PM, David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped
to 10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new
code seems to misbehave
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
On May 18, 2007, at 12:11 PM, David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and
Milton Miller wrote:
On May 18, 2007, at 12:11 PM, David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a
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
it looks OK,
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 it
looks OK, and I'll try to put
David Acker wrote:
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
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:
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
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and staying there...
ideas?
I found the problem.
David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and staying there...
ideas?
I
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 it looks OK, and
I'll try to put it under my
Milton Miller wrote:
In fact 6.4.3.4 says 82557 will start dropping frames immediately.
Looking at the descriptions around page 101:
(1) The link pointer, S, and EL is read when hw starts recieving the frame.
(2) Its pretty clear EL overrides S from the order of the descriptions
in the text.
Milton Miller wrote:
While this will help the problem with the cache-incoherent DMA systems
not running, it guarantees the hardware will stop every ring-size
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
[dropping Andrew, Jeff, and LKML]
On May 4, 2007, at 4:43 PM, David Acker wrote:
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
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 bits
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 positive logic:
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
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
50 matches
Mail list logo
