Frag lists cannot be deeper than one level of nesting,
and I think the recursive version is easier to understand,
so I really don't see the value of your change.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Chris Wedgwood <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 20:02:56 -0700
> will they go away completely at some point? lots of things that (for
> example) set interface addresses i bet use the ioctls and are not
> netlink aware (i'm guessing we have a libnetlink or something people
> can tr
Danial Thom wrote:
--- Ben Greear <[EMAIL PROTECTED]> wrote:
Danial Thom wrote:
I think the concensus is that 2.6 has made
trade
offs that lower raw throughput, which is what
a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A
raw
bridging
Danial Thom wrote:
--- Ben Greear <[EMAIL PROTECTED]> wrote:
Danial Thom wrote:
I think the concensus is that 2.6 has made
trade
offs that lower raw throughput, which is what
a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A
raw
bridging
Hi,
I noticed that skb_copy_datagram_iovec calls itself recursively to copy a
fragment list. This isn't actually wrong or even inefficient, it is just
somehow disturbing. Oh, and it uses an extra stack frame, and is hard to
read. Once I got started straightening that out, I couldn't resist clea
--- Ben Greear <[EMAIL PROTECTED]> wrote:
> Danial Thom wrote:
>
> > I think the concensus is that 2.6 has made
> trade
> > offs that lower raw throughput, which is what
> a
> > networking device needs. So as a router or
> > network appliance, 2.6 seems less suitable. A
> raw
> > bridging test
Danial Thom wrote:
I think the concensus is that 2.6 has made trade
offs that lower raw throughput, which is what a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A raw
bridging test on a 2.0Ghz operton system:
FreeBSD 4.9: Drops no packets at 900K pps
Li
On Wed, Aug 24, 2005 at 01:44:09PM -0700, David S. Miller wrote:
> It is intentional, BSD ioctls for configuration are
> deprecated, use netlink instead.
will they go away completely at some point? lots of things that (for
example) set interface addresses i bet use the ioctls and are not
netlink
This patch adds back the code that was taken out, thus re-enabling:
* The PHY Layer to initialize without crashing
* Drivers to actually connect to PHYs
* The entire PHY Control Layer
This patch is used by the gianfar driver, and other drivers which are in
development.
Signed-off-by: Andy Flemi
Update version and add 4 minor fixes, the last 2 were suggested by
Jeff Garzik:
1. check for a valid ethernet address before setting it
2. zero out bp->regview if init_one encounters an error and unmaps
the IO address. This prevents remove_one from unmapping again.
3. use netif_rx_schedule() in
Remove atomic operations in the fast tx path. Expensive atomic
operations were used to keep track of the number of available tx
descriptors. The new code uses the difference between the consumer
and producer index to determine the number of free tx descriptors.
As suggested by Jeff Garzik, the nam
This speeds up link-up time on 5706 SerDes if the link partner does
not autoneg, a rather common scenario in blade servers. Some blade
servers use IPMI for keyboard input and it's important to minimize
link disruptions.
The speedup is achieved by shortening the timer to (HZ / 3) during
the transie
This fixes an rtnl deadlock problem when flush_scheduled_work() is
called from bnx2_close(). In rare cases, linkwatch_event() may be on
the workqueue from a previous close of a different device and it will
try to get the rtnl lock which is already held by dev_close().
The fix is to set a flag if w
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/r8169.c~r8169-780 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-780 2005-08-24 23:11:15.947273681 +0200
+++ b/drivers/net/r8169.c 2005-08-24 23:11:15.991266546 +0200
@@ -857,6 +857,13 @@ static void rtl8169_ge
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/r8169.c~r8169-750 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-750 2005-08-24 21:54:10.027997437 +0200
+++ b/drivers/net/r8169.c 2005-08-24 21:54:10.065991272 +0200
@@ -444,37 +444,34 @@ static const u16 rtl8
Nothing fancy: the phy id is almost hardcoded per spec and
__mdio_{read/write} wrap around the existing mii access helpers.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/r8169.c~r8169-760 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-760 2005-08-24 22:30:28.32
phy_auto_nego_reg/phy_1000_ctrl_reg shadow some registers which could
be read through the (g)mii interface. Before they will be removed, one
notices that there are not even required in rtl8169_set_speed:
- if rtl8169_set_speed follows an invocation of rtl8169_set_speed_xmii,
the test against phy_
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/r8169.c~r8169-730 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-730 2005-08-24 21:54:06.195619312 +0200
+++ b/drivers/net/r8169.c 2005-08-24 21:54:06.222614932 +0200
@@ -398,7 +398,7 @@ struct rtl8169_private
The setting of the link parameters is a mess:
1 - the module option which (supposedly) forces the media parameters
actually enables autonegotiation. It has been done this way from
day one but it does not really qualify as an expected behavior;
2 - whatever the request, the ethtool interface
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/r8169.c~r8169-710 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-710 2005-08-24 21:54:03.760014518 +0200
+++ b/drivers/net/r8169.c 2005-08-24 21:54:03.786010300 +0200
@@ -444,11 +444,6 @@ static const u16 rtl81
These defines look generic but they are just a shift of the real mii
defines.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/r8169.c~r8169-700 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-700 2005-08-24 21:54:02.302251050 +0200
+++ b/drivers/net/r8169.c
Use the MII definitions which are available in include/linux/mii.h instead
of the redundant ones which are brought by the r8169 driver.
While at it:
- PHY_Cap_Null is not really useful;
- PHY_Auto_Neco_Comp (i.e. BMSR_ANEGCOMPLETE) is not used at all (uh...);
No functional change.
Signed-off-by:
PCI ID for the Linksys EG1032
Credit goes to Bob Wilson <[EMAIL PROTECTED]> for the report.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/r8169.c~r8169-680 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-680 2005-08-23 23:45:46.019410112 +0200
+++ b/drivers/net
Both revisions share the same PCI device ID and vendor ID but revision 2
of the device uses SysKonnect's chipset whereas revision 3 of the device
uses Realtek's 8169 chipset.
Credit goes to Christiaan Lutzer <[EMAIL PROTECTED]> for reporting
the issue and giving the actual value for the different
Richard Dawe <[EMAIL PROTECTED]> :
[...]
> Attached is a patch against 2.6.13-rc6 that converts the r8169 driver to
> use constants from for the MII registers, instead of using
> its own enums.
>
> Bye, Rich =]
>
> "r8169: Use constants from "
> Signed-off-by: Richard Dawe <[EMAIL PROTECTED]>
David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 10:14:22 -0700
I was thinking about somehow instrumenting dev_get and dev_put
(and __dev_get and __dev_put, I suppose) to keep a list of all
that have got and put, but that will be very invasive and time
consumi
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 11:33:19 -0700
> On Wed, 2005-08-24 at 15:52 -0400, Jeff Garzik wrote:
>
> > 2) Would prefer to follow the generic net stack and other areas of the
> > kernel, for the last piece of quoted code. net stack used to loop on
> > sched
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 16:02:46 -0400
> * I really like the fact that basically -nothing- happens in bnx2_msi()
> or bnx2_interrupt(). I'm glad to see that all the interrupt processing
> occurs from bnx2_poll(). I wish more drivers were written that way.
From: Steven Dake <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 12:41:25 -0700
> Is this intentional, or an oversight?
It is intentional, BSD ioctls for configuration are
deprecated, use netlink instead.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
On Wed, 2005-08-24 at 15:52 -0400, Jeff Garzik wrote:
> Three comments:
>
> 1) Since you may have to deal with the SMP case, don't you need to add
> wmb() or use atomic bit tests?
I don't think there will be any nasty races between bnx2_reset_task()
and bnx2_close(). If they are racing, the res
Michael Chan wrote:
David, a set of patches for bnx2 in netdev-2.6.14 will follow. The first
patch fixes a rare rtnl deadlock problem when flush_scheduled_work() is
called in the driver's close function. It looks like this may affect a
number of other drivers as well.
Misc unrelated comments:
Michael Chan wrote:
Update version and add 2 minor fixes: check for a valid ethernet
address before setting it and zero out bp->regview if init_one
encounters an error and unmaps the IO address. The 2nd fix prevents
remove_one from unmapping again.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Michael Chan wrote:
Change all locks from spin_lock_irqsave() to spin_lock_bh(). All
places that require spinlocks are in BH context.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Seems OK
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
Michael Chan wrote:
diff -rup c/drivers/net/bnx2.c d/drivers/net/bnx2.c
--- c/drivers/net/bnx2.c2005-08-24 07:22:12.0 -0700
+++ d/drivers/net/bnx2.c2005-08-24 07:24:37.0 -0700
@@ -107,6 +107,15 @@ static struct flash_spec flash_table[] =
MODULE_DEVICE_TABLE(pci,
Michael Chan wrote:
@@ -3906,6 +3923,11 @@ bnx2_open(struct net_device *dev)
return rc;
}
+ init_timer(&bp->timer);
+ bp->timer.expires = RUN_AT(bp->timer_interval);
+ bp->timer.data = (unsigned long) bp;
+ bp->timer.function = bnx2_timer;
+
rc
Michael Chan wrote:
This fixes an rtnl deadlock problem when flush_scheduled_work() is
called from bnx2_close(). In rare cases, linkwatch_event() may be on
the workqueue from a previous close of a different device and it will
try to get the rtnl lock which is already held by dev_close().
The fix
On Wed, Aug 24, 2005 at 07:05:28PM +, James Chapman wrote:
> I hadn't realized the mdio spin-wait could take 100us on this chip. In
> that case it makes sense to use the chip's MII status registers instead.
> At the same time, now that Andy Fleming's PHY abstraction code is
> available, the
I see in ipv4/devinet.c there is a call to register_gifconf which
registers a SIOCGIFCONF handler for the IPV4 protocol. There is no such
registration for ipv6. As a result, SIOCGIFCONF doesn't work for ipv6.
Is this intentional, or an oversight?
If its an oversight, I can work up a patch to add
Change all locks from spin_lock_irqsave() to spin_lock_bh(). All
places that require spinlocks are in BH context.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff -rup d/drivers/net/bnx2.c e/drivers/net/bnx2.c
--- d/drivers/net/bnx2.c2005-08-24 07:24:37.0 -0700
+++ e/drivers/
Update version and add 2 minor fixes: check for a valid ethernet
address before setting it and zero out bp->regview if init_one
encounters an error and unmaps the IO address. The 2nd fix prevents
remove_one from unmapping again.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff -rup e/drivers
Remove atomic operations in the fast tx path. Expensive atomic
operations were used to keep track of the number of available tx
descriptors. This uses the difference between the consumer and
producer index to determine the number of free tx descriptors.
Signed-off-by: Michael Chan <[EMAIL PROTECTE
This speeds up link-up time on 5706 SerDes if the link partner does
not autoneg, a rather common scenario in blade servers. Some blade
servers use IPMI for keyboard input and it's important to minimize
link disruptions.
The speedup is achieved by shortening the timer to (HZ / 3) during
the transie
This fixes an rtnl deadlock problem when flush_scheduled_work() is
called from bnx2_close(). In rare cases, linkwatch_event() may be on
the workqueue from a previous close of a different device and it will
try to get the rtnl lock which is already held by dev_close().
The fix is to set a flag if w
I hadn't realized the mdio spin-wait could take 100us on this chip. In
that case it makes sense to use the chip's MII status registers instead.
At the same time, now that Andy Fleming's PHY abstraction code is
available, the MII support should probably be changed over as BenH
suggested.
This
From: Mike Kershaw <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 09:39:00 -0400
> > Do you need to do some range validation on arg before setting
> > tun->dev->type?
>
> I shouldn't think so, the worst you could do is set it to a link type
> nothing understands, and then they just either go to cook
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 24 Aug 2005 10:14:22 -0700
> I was thinking about somehow instrumenting dev_get and dev_put
> (and __dev_get and __dev_put, I suppose) to keep a list of all
> that have got and put, but that will be very invasive and time
> consuming I fear...
That'
"extern inline" doesn't make much sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-rc6-mm2-full/include/net/ip_vs.h.old 2005-08-24
16:51:58.0 +0200
+++ linux-2.6.13-rc6-mm2-full/include/net/ip_vs.h 2005-08-24
16:51:38.0 +0200
@@ -958,7 +958,7 @@
Hello.
Attached is a patch against 2.6.13-rc6 that converts the r8169 driver to
use constants from for the MII registers, instead of using
its own enums.
Bye, Rich =]
"r8169: Use constants from "
Signed-off-by: Richard Dawe <[EMAIL PROTECTED]>
--- linux-2.6.13-rc6/drivers/net/r8169.c.orig
> Do you need to do some range validation on arg before setting tun->dev->type?
I shouldn't think so, the worst you could do is set it to a link type
nothing understands, and then they just either go to cooked socket
(pcap) or confuse the app (anything that looks at type directly) or
nothing (anyt
On Tue, Aug 23, 2005 at 05:28:00PM -0400, Mike Kershaw wrote:
> Very small patch to allow setting of the link type of the virtual tapX
> interfaces in tun/tap. Needed for writing packets of other arp link
> types to tap, ie 80211 wireless frames.
>
> Implemented as a simple IOCTL to set the arpty
Dennis <[EMAIL PROTECTED]> :
[...]
> Anyhow, I copied the folder under shell with scp. Under KDE 3.4 with
> konqueror and fish-protocol (which is ssh as far as I know), it still
> took much longer.
> So it´s a question of protocol?!?
I will not comment the efficiency of modern desktop application
Hi!
> You are optimistic :o)
That´s a good starting point, I think - otherwise I would have thrown my
Equipment out of a window many times already ;)
> I can get a fine 100Mb/s with this equipment + poor cables (a few tens of
> meters + same path as the power distribution). With this setup, neg
52 matches
Mail list logo
