The Software Developer Manual for the PRO/1000 PCI-e controllers is
now available via the http://e1000.sf.net/ web site. The file is
OpenSDM_8257x-10.pdf. I know it's been a long time coming but
sometimes that's just how it goes. Enjoy.
--
Cheers,
John
-
To unsubscribe from this list: send the
On 4/19/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> Off list lobbying usually has a negative impact.
The lobbying was for vendor inclusion and not necessarily for upstream
acceptance.
> The biggest barrier at this point seems to be hardware availability.
> People generally don't care unless
Please don't apply this patch. We have taken this offline at the
moment to work this out with the OEM, Aculab. They have made
modification to how the Intel controller operates which may make it
have problems with the normal e1000 driver. We are in contact with
both Mark and Aculab about this off
I ACK this patch.
Jeff please apply.
--
Cheers,
John
-
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
On 1/22/06, Ha Hi <[EMAIL PROTECTED]> wrote:
> Question one: when e1000 does packet splitting, it seems packet data buffer
> is splitted into three parts, but how does e1000 decide how many parts
> needed to be splitted?
The e1000 splits the packet into two parts, protocol headers and
payload data.
On 1/20/06, Lee Revell <[EMAIL PROTECTED]> wrote:
>
> Why don't these cause excessive scheduling delays in eepro100 then?
> Can't we just copy the eepro100 behavior?
Reports still float around from time to time about hangs with the
eepro100 which go away when the e100 driver is used. We don't
main
On 1/20/06, Lee Revell <[EMAIL PROTECTED]> wrote:
> Seems like the important question is, why does e100 need a watchdog if
> eepro100 works fine without one? Isn't the point of a watchdog in this
> context to work around other bugs in the driver (or the hardware)?
There are a number of things that
During the watchdog the e100 driver reads all of the status registers
from the actual hardware. There are 26 (worst case) register reads.
There is also a spin lock for another check in the watchdog. It would
still surprise me that all of this would take 500 usec. If you are
seeing this delay, y
We don't of any problems reported against e100 that have not been
talked about in this thread (in old ARCH types). I think the eepro100
driver should be removed from the config "just in case" but we are in
full support of the e100 driver and if somebody says that it's not
working on one of the dif
On 12/7/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> Keyword, "this box".
We don't disagree and never have with this. It's why we were asking
the question of find us a case where the prefetch shows a detriment to
performance. I think Jesse's data and recommendation of only keeping
the #1, #2
On 12/7/05, jamal <[EMAIL PROTECTED]> wrote:
> On the prefetch, i think would you agree now that it is problematic?
Sorry, I don't agree.
> I just showed that if i changed the cycle of execution between the
> moment the prefecth gets issued to the moment the data gets used we get
> different perf
On 12/7/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> Regardless of the decision, it's incorrect to point out e1000
> specifically as many other Linux networking drivers do copybreak too
> and I've always public advocated for copybreak to be used by drivers
> due to the socket buffering issue.
On 12/7/05, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> So... under load, copybreak causes e1000 to fall over more rapidly than
> no-copybreak?
>
> If so, it sounds like copybreak should be disabled by default, and/or a
> runtime switched added for it.
I wouldn't say "fall over". With small packet o
On 12/7/05, Robert Olsson <[EMAIL PROTECTED]> wrote:
> Thanks for this discussion. It comes in handy as I have to prepare
> for a new distro for our network stuff. Right now it seems like
> e1000 6.2.15 can be used but with HW-flow disabled, cpybrk disabled
> and only with the two first prefetches
On 12/7/05, jamal <[EMAIL PROTECTED]> wrote:
> It is possible it will help some traffic setups to turn it on, however,
> forever you had it as off. So people who need it know how to turn it on.
> The sudden change of behavior that was questionable and btw it is not
> documented either.
Well it's a
On 12/2/05, Grant Grundler <[EMAIL PROTECTED]> wrote:
> Yup. We can tune for workload/load-latency of each architecture.
> I think tuning for all of them in one source code is the current problem.
> We have to come up with a way for the compiler to insert (or not)
> prefetching at different places
At long last the software developers manual for the Intel PRO/1000
Gigabit Ethernet controllers is now available on our Sourceforge web
site. The URL is: http://sourceforge.net/projects/e1000
The manual covers all of the PCI/PCI-X controllers supported by the
e1000 driver. We will be following t
17 matches
Mail list logo
