Jeff Garzik posted a series of five patches for the forcedeth driver which he described as, "several proposed updates for testing". Forcedeth is a GPL'd driver for the Ethernet interface of the NVIDIA nForce chipset, originally merged into the 2.4.26 and 2.6.5 Linux kernels. Jeff noted two main goals for the patches:
"1) move the driver towards a more sane, simple, easy to verify locking setup -- irq handler would often acquire/release the lock twice for each interrupt.
"2) to eliminate a rarely used, apparently fragile locking scheme that includes heavy use of disable_irq(). this tool is most often employed during NIC reset/reconfiguration, so satisfying this goal implies changing the way NIC reset and config are accomplished."
Jeff explained that he was looking to get the changes tested, "these are intended for feedback and testing, NOT for merging." He went on to explain that one of the changes included two independent napi_structs, one for receiving and one transmitting, "I feel TX NAPI is a useful tool, because it provides an independent TX process control point and system load feedback point. Thus I felt this was slightly superior to tasklets. But who knows if this is a good idea? :) I am interested in feedback and criticism on this issue."
From: Jeff Garzik <jeff@...>
Subject: [PATCH 0/5] forcedeth: several proposed updates for testing
Date: Oct 6, 11:12 am 2007
The 'fe-lock' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock
contains the following changes that I would like to get tested:
[netdrvr] forcedeth: make NAPI unconditional
[netdrvr] forcedeth: interrupt handling cleanup
[netdrvr] forcedeth: process TX completions using NAPI
[netdrvr] forcedeth: internal simplification and cleanups
[netdrvr] forcedeth: timer overhaul
These are intended for feedback and testing, NOT for merging.
The goals of these changes are:
* move the driver towards a more sane, simple, easy to verify locking
setup -- irq handler would often acquire/release the lock twice
for each interrupt -- and hopefully
* to eliminate a rarely used, apparently fragile locking scheme that
includes heavy use of disable_irq(). this tool is most often employed
during NIC reset/reconfiguration, so satisfying this goal implies
changing the way NIC reset and config are accomplished.
Miscellaneous notes:
* using the new napi_struct stuff in net-2.6.24, the TX completion
process has been moved to a -separate- NAPI polling channel. thus
there are now two napi_structs, one for RX and one for TX, independent
of each other.
* I feel TX NAPI is a useful tool, because it provides an independent TX
process control point and system load feedback point.
Thus I felt this was slightly superior to tasklets.
* But who knows if this is a good idea? :) I am interested in
feedback and criticism on this issue.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux *still* doesn't have
Linux *still* doesn't have support for these NICs? Wow, seems to take as long as it took to get IPv6 into Linux too.
Why is Linux developments so slow at times? Does it have to do with all it's various, non-standard, fragmented distros and overly fragmented development model?
I'm curious...
from what i understand, the
from what i understand, the support have been in the kernel since at least 2.6.5, and we are not using 2.6.22.x so do the math...
this is for some added functionality to the driver. stuff thats not vital to its functioning, but could be nice to have.
Actually the locking and IRQ
Actually the locking and IRQ handling in the driver are quite necessary for the driver to work and these patches clean that up.
Say WHAT? Support for these
Say WHAT? Support for these devices has been in the kernel for about 2 years I think. I have an AMD64 mobo bought in 2005 with NVidia 1gbit Ethernet onboard, and it "just worked" out of the box with the forcedeth drivers. No problems whatsoever, and excellent performance (better than under Windows XP, I should add!)
This is just a patch to IMPROVE these drivers.
Kernel development has nothing to do with distro fragmentation. Stop trolling.
Forcedeth already works superbly
The forcedeth ethernet driver has run to perfection for my Gigabyte/Nvidia board for several months with kernels 2.6.21-2.6.23. I am sure these updates just improve already excellent code.
You're a troll, it states
You're a troll, it states clearly that linux supports these drivers.