[ANNOUNCE] NAPI patches for 2.4.19-rc1

[ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jason Lunz]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]


I've backported the most recent napi sources I could find to 2.4.19-rc1.
The patches are available at http://orr.falooley.org/pub/linux/net/.

Testing and suggestions are welcome. Currently backported napi drivers
are e1000, eepro100, tulip, and 3c59x. I intend to backport dl2k and
sundance at some point, but I have no dl2k cards and I'm working with
Donald Becker to get the sundance driver working on the card I have.

Does anyone know of more recent NAPI conversions? Robert Olsson tells me
Jeff Garzik has a more recent tulip conversion, but there are _no_ napi
net drivers in 2.5.25 and I haven't found any others except for those
mentioned at the NAPI ftp site.

Jason

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Ben Greear]

Jason Lunz wrote:
> I've backported the most recent napi sources I could find to 2.4.19-rc1.
> The patches are available at http://orr.falooley.org/pub/linux/net/.
> 
> Testing and suggestions are welcome. Currently backported napi drivers
> are e1000, eepro100, tulip, and 3c59x. I intend to backport dl2k and
> sundance at some point, but I have no dl2k cards and I'm working with
> Donald Becker to get the sundance driver working on the card I have.
> 
> Does anyone know of more recent NAPI conversions? Robert Olsson tells me
> Jeff Garzik has a more recent tulip conversion, but there are _no_ napi
> net drivers in 2.5.25 and I haven't found any others except for those
> mentioned at the NAPI ftp site.
> 
> Jason

The tulip driver I saw on the napi web site was based off of the one
in kernel 2.4.2, which was back when tulip was broken for a lot of
cards (especially mine).

Is that where you got the basis for this last port?

Thanks, I'll try out the tulip and NAPI patches ASAP.

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jason Lunz]

On Wed, Jul 10, 2002 at  3:56PM -0700, Ben Greear wrote:
> The tulip driver I saw on the napi web site was based off of the one
> in kernel 2.4.2, which was back when tulip was broken for a lot of
> cards (especially mine).
> 
> Is that where you got the basis for this last port?

I asked Robert Olssen about this a while back; he said that it was based
on the driver in 2.5.3 "to make Jeff happy".

Jason

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[jamal]

For some reason i thought there was already patches for 2.4.18 and above.
Robert, seems like you dont have them;
Two patches:
2.4.18: http://www.cyberus.ca/~hadi/patches/napi-patch-2418.gz
2.4.19-pre10: http://www.cyberus.ca/~hadi/patches/napi-2419-pre10.gz

Also a more recently tested tulip driver at:
http://www.cyberus.ca/~hadi/patches/tulip-napi.tgz
tested with Znyx 4 port ethernet cards;
For the best perfomance (at least on the Znyx Nics) turn on MMIO
(selected from kernel config). Ignore anything that looks strange
in the code. The dl2k and sundance driver from Ed Peng listed in the
README at the site should work fine on 2.4

The info is at:
ftp://robur.slu.se/pub/Linux/net-development/NAPI/README

cheers,
jamal

On Wed, 10 Jul 2002, Jason Lunz wrote:

>
> I've backported the most recent napi sources I could find to 2.4.19-rc1.
> The patches are available at http://orr.falooley.org/pub/linux/net/.
>
> Testing and suggestions are welcome. Currently backported napi drivers
> are e1000, eepro100, tulip, and 3c59x. I intend to backport dl2k and
> sundance at some point, but I have no dl2k cards and I'm working with
> Donald Becker to get the sundance driver working on the card I have.
>
> Does anyone know of more recent NAPI conversions? Robert Olsson tells me
> Jeff Garzik has a more recent tulip conversion, but there are _no_ napi
> net drivers in 2.5.25 and I haven't found any others except for those
> mentioned at the NAPI ftp site.
>
> Jason
>

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Donald Becker]

On Wed, 10 Jul 2002, jamal wrote:
...
> For the best perfomance (at least on the Znyx Nics) turn on MMIO
> (selected from kernel config). Ignore anything that looks strange
> in the code. The dl2k and sundance driver from Ed Peng listed in the
> README at the site should work fine on 2.4

Ehhh?  Has anyone tested that sundance driver with the Kendin chip using
the on-chip transceiver?  I'm guessing that it doesn't work.

And, BTW, I don't like some of the driver changes in that version.

One pair of changes that represent "it works for me" code and flawed
reasoning is resetting the transceiver and then calling mdelay(300).

Unless there is a specific known hardware problem, the driver should not
reset the transceiver and thus re-do autonegotiation.  Some switches
(Cisco) turn off traffic to that port for a minute when link beat is
lost, and some operations rely on being able to rapidly bring the
interface up and down.

The mdelay(300) is completely bogus.  While that is a typical period for
autonegotiation to complete on a short link, the spec says that it can
take up to 3 seconds, 10X longer, to complete autonegotiation.  Given
that the driver must be able to handle a longer autonegotiation period
and no link beat, why call mdelay() at all?

The driver also changes the transceiver settings to non-standard
values.  Yes, the change might seem more descriptive, but the modified
driver doesn't match the documentation or accept the options that other
drivers do.  There is a value to consistency: "/bin/list" is more
descriptive than  "/bin/ls", but you don't see any distribution trying
to rename 'ls'... 

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jeff Garzik]

Donald Becker wrote:
> The mdelay(300) is completely bogus.  While that is a typical period for
> autonegotiation to complete on a short link, the spec says that it can
> take up to 3 seconds, 10X longer, to complete autonegotiation.  Given
> that the driver must be able to handle a longer autonegotiation period
> and no link beat, why call mdelay() at all?

Ouch.  You are absolutely right, and I take the blame for not reviewing 
more closely.  That's what I get for trusting vendors too much ;-) 
[D-Link has been the one patching sundance and dl2k for a while now]

I've been meaning to go through several drivers and fix up the stupid 
assumptions they make about autonegotiation completion time.  There are 
a couple other drivers that do somewhat the same thing, though with a 
different [if equally silly] implementation.

And finally, most drivers need to be updated to follow the logic:  call 
netif_carrier_off().  Wait for autoneg complete and link OK, before 
calling netif_carrier_on().


> The driver also changes the transceiver settings to non-standard
> values.  Yes, the change might seem more descriptive, but the modified
> driver doesn't match the documentation or accept the options that other
> drivers do.  There is a value to consistency: "/bin/list" is more
> descriptive than  "/bin/ls", but you don't see any distribution trying
> to rename 'ls'... 

Which lines of code are you referring to?

This _might_ be a case where the docs are inaccurate, since the patch 
was done by D-Link with access to the chip designers.

	Jeff

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Donald Becker]

On Thu, 11 Jul 2002, Jeff Garzik wrote:
> Donald Becker wrote:
> > The mdelay(300) is completely bogus.
...
> Ouch.  You are absolutely right, and I take the blame for not reviewing 
> more closely.  That's what I get for trusting vendors too much ;-)
> [D-Link has been the one patching sundance and dl2k for a while now]

Very, very few vendor patchs are worth applying.  They sometimes know of
otherwise undocumented chip bugs, but a lot of the actual code is bad.

It's not "maintaining" a driver when you just take a vendor modification
of a driver and assume it's OK.  You have to understand the changes and
evaluate if they make sense.

> I've been meaning to go through several drivers and fix up the stupid 
> assumptions they make about autonegotiation completion time.

Putting broken changes into the kernel with a plan to go back later and
clean them is a bad development methodology.

> > The driver also changes the transceiver settings to non-standard
> > values.
> Which lines of code are you referring to?

Removing "options" as a way to set the transceiver.

> This _might_ be a case where the docs are inaccurate, since the patch 
> was done by D-Link with access to the chip designers.

No, it's unrelated to specific chip.  It's a change that looks good when
you see only that driver, but the change makes it inconsistent will all
of the other drivers.  

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Ben Greear]

Donald Becker wrote:

> Very, very few vendor patchs are worth applying.  They sometimes know of
> otherwise undocumented chip bugs, but a lot of the actual code is bad.
> 
> It's not "maintaining" a driver when you just take a vendor modification
> of a driver and assume it's OK.  You have to understand the changes and
> evaluate if they make sense.

I don't know the quality of the patches submitted by dlink, but I do
know that the existing driver in the 2.4.18 kernel absolutely does not
work at all.  So, if there is a hack/patch that makes it work, I consider
that better than completely broken, even if it is ugly.

Of course, the preferred driver would be clean and work with all chipsets,
but those are not easy to find.

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jeff Garzik]

Ben Greear wrote:
> I don't know the quality of the patches submitted by dlink, but I do
> know that the existing driver in the 2.4.18 kernel absolutely does not
> work at all.  So, if there is a hack/patch that makes it work, I consider
> that better than completely broken, even if it is ugly.


I thought that issue was fixed in 2.4.19-rc1?  Can you verify the 
problem still exists?

	Jeff

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Ben Greear]

Jeff Garzik wrote:
> Ben Greear wrote:
> 
>> I don't know the quality of the patches submitted by dlink, but I do
>> know that the existing driver in the 2.4.18 kernel absolutely does not
>> work at all.  So, if there is a hack/patch that makes it work, I consider
>> that better than completely broken, even if it is ugly.
> 
> 
> 
> I thought that issue was fixed in 2.4.19-rc1?  Can you verify the 
> problem still exists?
> 
>     Jeff

About to pack and move to Washington state, but will test it as soon
as I get the lab powered up again :)

I have not tried with rc1, so it very well could be fixed.


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jason Lunz]

greearb@candelatech.com said:
>> I thought that issue was fixed in 2.4.19-rc1?  Can you verify the 
>> problem still exists?
>>     Jeff
> I have not tried with rc1, so it very well could be fixed.

The 2.4.19-rc1 sundance driver (sundance.c:v1.01b 17-Jan-2002) does not
work with my DLink 4-port DFE-580TX. As Donald mentioned earlier, newer
Kendin sundance chips have a finicky on-chip transceiver. I'll be
testing various sundance drivers on this card today.

Jason

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Donald Becker]

On Thu, 11 Jul 2002, Ben Greear wrote:

> > Very, very few vendor patchs are worth applying.  They sometimes know of
> > otherwise undocumented chip bugs, but a lot of the actual code is bad.
> > 
> > It's not "maintaining" a driver when you just take a vendor modification
> > of a driver and assume it's OK.  You have to understand the changes and
> > evaluate if they make sense.
> 
> I don't know the quality of the patches submitted by dlink, but I do
> know that the existing driver in the 2.4.18 kernel absolutely does not
> work at all.

It's a driver that _did_ work, but untested changes were made.

> So, if there is a hack/patch that makes it work, I consider
> that better than completely broken, even if it is ugly.

The DLink modified driver is still missing a few important changes for the
new chip version in MMIO mode.  For instance, ASICCtrl apparently must
now be read and written as a 32 bit word, while the older chip worked
with writew().

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jeff Garzik]

Donald Becker wrote:
> On Thu, 11 Jul 2002, Jeff Garzik wrote:
> 
>>Donald Becker wrote:
>>
>>>The mdelay(300) is completely bogus.
>>
> ...
> 
>>Ouch.  You are absolutely right, and I take the blame for not reviewing 
>>more closely.  That's what I get for trusting vendors too much ;-)
>>[D-Link has been the one patching sundance and dl2k for a while now]
> 
> 
> Very, very few vendor patchs are worth applying.  They sometimes know of
> otherwise undocumented chip bugs, but a lot of the actual code is bad.
> 
> It's not "maintaining" a driver when you just take a vendor modification
> of a driver and assume it's OK.  You have to understand the changes and
> evaluate if they make sense.

I never claimed to maintain sundance ;-)  Not having docs and test 
hardware tends to narrow the field a bit.


>>I've been meaning to go through several drivers and fix up the stupid 
>>assumptions they make about autonegotiation completion time.
> 
> 
> Putting broken changes into the kernel with a plan to go back later and
> clean them is a bad development methodology.

That depends on the change.  mdelay(300) is a case of "stupid but 
usually works" not completely broken.  As long as it's forward progress 
that gets something working, I would rather apply now and fix up later. 
  That reduces the overall brokenness time a user must deal with.

I'm accepting patches to clean up sundance, if someone with test 
hardware is willing to compare your driver and the kernel's.

	Jeff

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jason Lunz]

On Wed, Jul 10, 2002 at  7:34PM -0400, jamal wrote:
> For some reason i thought there was already patches for 2.4.18 and above.
> Robert, seems like you dont have them;
> Two patches:
> 2.4.18: http://www.cyberus.ca/~hadi/patches/napi-patch-2418.gz
> 2.4.19-pre10: http://www.cyberus.ca/~hadi/patches/napi-2419-pre10.gz

ah, thanks! The napi README links to the usenix paper on your site, but
doesn't mention the patches directory.

> Also a more recently tested tulip driver at:
> http://www.cyberus.ca/~hadi/patches/tulip-napi.tgz

great, I'll check it out too.

> tested with Znyx 4 port ethernet cards; For the best perfomance (at
> least on the Znyx Nics) turn on MMIO (selected from kernel config).

Do you know if this would also apply to the DLink 4-port tulip cards
(DFE-570TX)? They're based on intel 21143's.

Jason

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jeff Garzik]

Jason Lunz wrote:
> On Wed, Jul 10, 2002 at  7:34PM -0400, jamal wrote:
>>tested with Znyx 4 port ethernet cards; For the best perfomance (at
>>least on the Znyx Nics) turn on MMIO (selected from kernel config).
> 
> 
> Do you know if this would also apply to the DLink 4-port tulip cards
> (DFE-570TX)? They're based on intel 21143's.

Yes, MMIO will speed up pretty much any tulip card

	Jeff

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jason Lunz]

On Thu, Jul 11, 2002 at  9:39AM -0400, Jeff Garzik wrote:
> Yes, MMIO will speed up pretty much any tulip card

Why isn't it the default? Because the clones don't handle it?

Jason

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Donald Becker]

On Thu, 11 Jul 2002, Jason Lunz wrote:

> On Thu, Jul 11, 2002 at  9:39AM -0400, Jeff Garzik wrote:
> > Yes, MMIO will speed up pretty much any tulip card
> 
> Why isn't it the default? Because the clones don't handle it?

It's the default in my driver, with -DUSE_IO_OPS to override.
The driver did need additional write flushes with a few operations.  Don't
do this blindly, or you will end up with a driver that is much
slower than just using I/O operations (e.g. early 8139too drivers).

When I made the changes, I tested on a few dozen tulip cards.  Do not
change a driver unless you have access to all of the chips and chip
revisions, as well as boards with all of the transceiver options.

There are a few NICs that either don't work with MMIO, or have different
register semantics.  Early via-rhine chips and the rtl8139 are good
examples.  Don't assume that if it works for you, the change is
universally valid.


-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993

Re: [ANNOUNCE] NAPI patches for 2.4.19-rc1

[Jeff Garzik]

Jason Lunz wrote:
> On Thu, Jul 11, 2002 at  9:39AM -0400, Jeff Garzik wrote:
> 
>>Yes, MMIO will speed up pretty much any tulip card
> 
> 
> Why isn't it the default? Because the clones don't handle it?


tulip still has PCI posting bugs [1], and some clones don't support MMIO 
at all.

	Jeff



[1] you only notice this on a few chipsets, typically non-ia32 ones

[ANNOUNCE] NAPI patches for 2.4.19-rc1

[Robert Olsson]

Jason Lunz writes:
 > 
 > I've backported the most recent napi sources I could find to 2.4.19-rc1.
 > The patches are available at http://orr.falooley.org/pub/linux/net/.

 Thanks!
 Yes but remember it's experimental branch and hopefully soon we can kill 
 most of it... 

 > Does anyone know of more recent NAPI conversions? Robert Olsson tells me
 > Jeff Garzik has a more recent tulip conversion, but there are _no_ napi
 > net drivers in 2.5.25 and I haven't found any others except for those
 > mentioned at the NAPI ftp site.

 Current tulip seems fine but it is complex. Eventually it will be  better 
 if uses a simliar scheme as e1000 and tg3. Leaving all "interrupt work" to 
 dev->poll. And yes it was forked off linux-2.4.2 so Jeffs later work is
 not included.

 
 The e1000 4.2.4 is well tested. But for 4.2.17 I more or less moved the path 
 onto it.

 I've put a reference to your work in README

 Cheers.

						--ro