* Re: [PATCH] [SIS190] Constify data marked as __devinitdata
From: Sam Ravnborg @ 2008-01-30 13:37 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Jonas Bonn, netdev, romieu, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0801301429230.15249@fbirervta.pbzchgretzou.qr>
On Wed, Jan 30, 2008 at 02:31:05PM +0100, Jan Engelhardt wrote:
>
> On Jan 30 2008 12:25, Sam Ravnborg wrote:
> >
> >We have just introduced __initconst, __cpuinitconst, __meminitconst
> >for const data.
> >So the patch is wrong.
>
> Oh joy, more tags. Is it actually possible to combine const
> with __devinitconst now?
>
> static const uint16_t foo[] __devinitconst = { ... };
Yes, try it.
Sam
^ permalink raw reply
* [PATCH] [SIS190] Use __devinitconst for const devinit data
From: Jonas Bonn @ 2008-01-30 13:41 UTC (permalink / raw)
To: netdev, romieu, linux-kernel; +Cc: Jonas Bonn
In-Reply-To: <20080130133742.GA22198@uranus.ravnborg.org>
Mixing const and __section was previously not allowed. New __devinitconst tag
allows this.
This fixes a gcc "section type mismatch" build error.
---
drivers/net/sis190.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index b570402..d3126a9 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -326,7 +326,7 @@ static const struct {
{ "SiS 191 PCI Gigabit Ethernet adapter" },
};
-static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
+static const struct pci_device_id sis190_pci_tbl[] __devinitconst = {
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
{ PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
{ 0, },
@@ -1556,7 +1556,7 @@ static int __devinit sis190_get_mac_addr_from_eeprom(struct pci_dev *pdev,
static int __devinit sis190_get_mac_addr_from_apc(struct pci_dev *pdev,
struct net_device *dev)
{
- static const u16 __devinitdata ids[] = { 0x0965, 0x0966, 0x0968 };
+ static const u16 __devinitconst ids[] = { 0x0965, 0x0966, 0x0968 };
struct sis190_private *tp = netdev_priv(dev);
struct pci_dev *isa_bridge;
u8 reg, tmp8;
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] [2/2] Remove some unnecessary gotos in established_get_first()
From: David Miller @ 2008-01-30 13:46 UTC (permalink / raw)
To: oliver; +Cc: netdev
In-Reply-To: <200801300925.12397.oliver@neukum.org>
From: Oliver Neukum <oliver@neukum.org>
Date: Wed, 30 Jan 2008 09:25:12 +0100
> Now suppose somebody needs to change locking. He'll have to convert
> it back. IMHO a conditional return is worse than "goto clearly_named_label"
I totally agree.
^ permalink raw reply
* Re: net-2.6.25 is no more...
From: David Miller @ 2008-01-30 13:48 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <47A03D4D.5090301@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Wed, 30 Jan 2008 10:03:09 +0100
> David Miller wrote:
> > Now that the bulk has been merged over and we are
> > actively working alongside Linus's tree I have moved
> > all current patch applying to net-2.6 instead of net-2.6.25,
> > so the current tree to use is:
> >
> > kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
>
> This tree is for fixes only, right ? or shall we send enhancement
> patches to net-2.6 until net-2.6.26 appears ?
The latter.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: David Miller @ 2008-01-30 13:53 UTC (permalink / raw)
To: ballen; +Cc: linux-kernel, henning.fehrmann, carsten.aulbert, bruce.allen,
netdev
In-Reply-To: <Pine.LNX.4.63.0801300324000.6391@trinity.phys.uwm.edu>
From: Bruce Allen <ballen@gravity.phys.uwm.edu>
Date: Wed, 30 Jan 2008 03:51:51 -0600 (CST)
[ netdev@vger.kernel.org added to CC: list, that is where
kernel networking issues are discussed. ]
> (The performance of a full duplex stream should be close to 1Gb/s in
> both directions.)
This is not a reasonable expectation.
ACKs take up space on the link in the opposite direction of the
transfer.
So the link usage in the opposite direction of the transfer is
very far from zero.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 14:01 UTC (permalink / raw)
To: netdev, Linux Kernel Mailing List, David Miller
Cc: Henning Fehrmann, Carsten Aulbert, Bruce Allen
In-Reply-To: <20080130.055333.192844925.davem@davemloft.net>
Hi David,
Thanks for your note.
>> (The performance of a full duplex stream should be close to 1Gb/s in
>> both directions.)
>
> This is not a reasonable expectation.
>
> ACKs take up space on the link in the opposite direction of the
> transfer.
>
> So the link usage in the opposite direction of the transfer is
> very far from zero.
Indeed, we are not asking to see 1000 Mb/s. We'd be happy to see 900
Mb/s.
Netperf is trasmitting a large buffer in MTU-sized packets (min 1500
bytes). Since the acks are only about 60 bytes in size, they should be
around 4% of the total traffic. Hence we would not expect to see more
than 960 Mb/s.
We have run these same tests on older kernels (with Broadcomm NICS) and
gotten above 900 Mb/s full duplex.
Cheers,
Bruce
^ permalink raw reply
* [drivers/net/bnx2.c] ADVERTISE_1000XPSE_ASYM
From: Roel Kluin @ 2008-01-30 14:07 UTC (permalink / raw)
To: mchan, lkml; +Cc: netdev
In drivers/net/bnx2.c:1285: it reads in function bnx2_setup_remote_phy():
if (pause_adv & (ADVERTISE_1000XPSE_ASYM | ADVERTISE_1000XPSE_ASYM))
Note that the two are the same and this is therefore equivalent to
if (pause_adv & ADVERTISE_1000XPSE_ASYM)
This appears to be incorrect, was maybe '| ADVERTISE_1000XPAUSE' intended?
^ permalink raw reply
* [PATCH][net/sched/sch_teql.c] duplicate IFF_BROADCAST in FMASK, remove 2nd
From: Roel Kluin @ 2008-01-30 14:36 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, lkml
Untested patch below, please confirm it's the right fix (should it be some
other IFF_*?)
--
duplicate IFF_BROADCAST, remove 2nd
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/net/sched/sch_teql.c b/net/sched/sch_teql.c
index c0ed06d..a53acf4 100644
--- a/net/sched/sch_teql.c
+++ b/net/sched/sch_teql.c
@@ -71,7 +71,7 @@ struct teql_sched_data
#define NEXT_SLAVE(q) (((struct teql_sched_data*)qdisc_priv(q))->next)
-#define FMASK (IFF_BROADCAST|IFF_POINTOPOINT|IFF_BROADCAST)
+#define FMASK (IFF_BROADCAST|IFF_POINTOPOINT)
/* "teql*" qdisc routines */
^ permalink raw reply related
* Re: [PATCH 1/3] netns netfilter: semi-rewrite of /proc/net/foo_tables_*
From: Patrick McHardy @ 2008-01-30 15:17 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev, netfilter-devel, devel
In-Reply-To: <20080125164314.GE6028@localhost.sw.ru>
Alexey Dobriyan wrote:
> Argh, there are many small but still wrong things with /proc/net/*_tables_*
> so I decided to do overhaul simultaneously making it more suitable for
> per-netns /proc/net/*_tables_* implementation.
>
> Fix
> a) xt_get_idx() duplicating now standard seq_list_start/seq_list_next
> iterators
> b) tables/matches/targets list was chosen again and again on every ->next
> c) multiple useless "af >= NPROTO" checks -- we simple don't supply invalid
> AFs there and registration function should BUG_ON instead.
>
> Regardless, the one in ->next() is the most useless -- ->next doesn't
> run at all if ->start fails.
> d) Don't use mutex_lock_interruptible() -- it can fail and ->stop is
> executed even if ->start failed, so unlock without lock is possible.
>
> As side effect, streamline code by splitting xt_tgt_ops into xt_target_ops,
> xt_matches_ops, xt_tables_ops.
>
> xt_tables_ops hooks will be changed by per-netns code. Code of
> xt_matches_ops, xt_target_ops is identical except the list chosen for
> iterating, but I think consolidating code for two files not worth it
> given "<< 16" hacks needed for it.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
Applied, and I also removed the now unused TABLE/TARGET/MATCH enum.
^ permalink raw reply
* Re: [PATCH 2/3] netns netfilter: netns propagation for /proc/net/*_tables_names
From: Patrick McHardy @ 2008-01-30 15:17 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev, netfilter-devel, devel
In-Reply-To: <20080125164429.GF6028@localhost.sw.ru>
Alexey Dobriyan wrote:
> Propagate netns together with AF down to ->start/->next/->stop
> iterators. Choose table based on netns and AF for showing.
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] netns netfilter: create per-netns /proc/net/*_tables_*
From: Patrick McHardy @ 2008-01-30 15:17 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev, netfilter-devel, devel
In-Reply-To: <20080125164529.GG6028@localhost.sw.ru>
Alexey Dobriyan wrote:
> Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
> ---
>
> include/linux/netfilter/x_tables.h | 4 ++--
> net/ipv4/netfilter/arp_tables.c | 21 ++++++++++++++++++---
> net/ipv4/netfilter/ip_tables.c | 21 ++++++++++++++++++---
> net/ipv6/netfilter/ip6_tables.c | 22 +++++++++++++++++++---
> net/netfilter/x_tables.c | 20 ++++++++++----------
> 5 files changed, 67 insertions(+), 21 deletions(-)
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH] NET: constify data and function pointer tables
From: John W. Linville @ 2008-01-30 16:11 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan Engelhardt, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <47A0427D.7040301-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
On Wed, Jan 30, 2008 at 04:25:17AM -0500, Jeff Garzik wrote:
> Jan Engelhardt wrote:
>> Signed-off-by: Jan Engelhardt <jengelh-bdq14YP6qtRlEiWPh9xO2Q@public.gmane.org>
>> ---
>> drivers/net/bonding/bond_main.c | 2 +-
>> drivers/net/hamradio/bpqether.c | 2 +-
>> drivers/net/hamradio/scc.c | 2 +-
>> drivers/net/hamradio/yam.c | 2 +-
>> drivers/net/ibmveth.c | 2 +-
>> drivers/net/pppoe.c | 2 +-
>> drivers/net/pppol2tp.c | 4 ++--
>> drivers/net/wireless/libertas/debugfs.c | 14 +++++++-------
>> drivers/net/wireless/strip.c | 2 +-
>> 9 files changed, 16 insertions(+), 16 deletions(-)
>
> ACK -- but you should collect linville's ack of the wireless stuff too
> (even though the patch is simple and obvious)
Looks fine to me...ACK
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* [BUILD FAILURE] 2.6.24-git7 section type conflict at various drivers on powerpc
From: Kamalesh Babulal @ 2008-01-30 16:19 UTC (permalink / raw)
To: LKML, netdev, linuxppc-dev, Sam Ravnborg, Andy Whitcroft
Hi,
Following are the different build failure with 2.6.24-git7 kernel on the powerpc
drivers/net/typhoon.c:181: error: typhoon_card_info causes a section type conflict
make[2]: *** [drivers/net/typhoon.o] Error 1
drivers/net/natsemi.c:259: error: natsemi_pci_info causes a section type conflict
make[2]: *** [drivers/net/natsemi.o] Error 1
drivers/net/bnx2.c:95: error: board_info causes a section type conflict
make[2]: *** [drivers/net/bnx2.o] Error 1
drivers/net/via-velocity.c:454: error: velocity_id_table causes a section type conflict
make[2]: *** [drivers/net/via-velocity.o] Error 1
Following are warning with section mismatch CONFIG_DEBUG_SECTION_MISMATCH enabled,
WARNING: kernel/built-in.o(.text+0x423f4): Section mismatch in reference from the function .enable_nonboot_cpus() to the function .cpuinit.text:._cpu_up()
The function .enable_nonboot_cpus() references
the function __cpuinit ._cpu_up().
This is often because .enable_nonboot_cpus lacks a __cpuinit
annotation or the annotation of ._cpu_up is wrong.
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.devinit.text+0x1bb4): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.tah_detach()
The function __devinit .emac_probe() references
a function __devexit .tah_detach().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.tah_detach() so it may be used outside an exit section.
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.devinit.text+0x1bd0): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.rgmii_detach()
The function __devinit .emac_probe() references
a function __devexit .rgmii_detach().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.rgmii_detach() so it may be used outside an exit section.
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.devinit.text+0x1bec): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.zmii_detach()
The function __devinit .emac_probe() references
a function __devexit .zmii_detach().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.zmii_detach() so it may be used outside an exit section.
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.devinit.text+0x1bfc): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.mal_unregister_commac()
The function __devinit .emac_probe() references
a function __devexit .mal_unregister_commac().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.mal_unregister_commac() so it may be used outside an exit section.
LD drivers/net/ibm_newemac/built-in.o
WARNING: drivers/net/ibm_newemac/built-in.o(.devinit.text+0x1bb4): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.tah_detach()
The function __devinit .emac_probe() references
a function __devexit .tah_detach().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.tah_detach() so it may be used outside an exit section.
WARNING: drivers/net/ibm_newemac/built-in.o(.devinit.text+0x1bd0): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.rgmii_detach()
The function __devinit .emac_probe() references
a function __devexit .rgmii_detach().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.rgmii_detach() so it may be used outside an exit section.
WARNING: drivers/net/ibm_newemac/built-in.o(.devinit.text+0x1bec): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.zmii_detach()
The function __devinit .emac_probe() references
a function __devexit .zmii_detach().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.zmii_detach() so it may be used outside an exit section.
WARNING: drivers/net/ibm_newemac/built-in.o(.devinit.text+0x1bfc): Section mismatch in reference from the function .emac_probe() to the function .devexit.text:.mal_unregister_commac()
The function __devinit .emac_probe() references
a function __devexit .mal_unregister_commac().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
.mal_unregister_commac() so it may be used outside an exit section.
WARNING: drivers/net/mlx4/mlx4_core.o(.text+0x6cf8): Section mismatch in reference from the function .mlx4_init_icm() to the function .devinit.text:.mlx4_init_cmpt_table()
The function .mlx4_init_icm() references
the function __devinit .mlx4_init_cmpt_table().
This is often because .mlx4_init_icm lacks a __devinit
annotation or the annotation of .mlx4_init_cmpt_table is wrong.
WARNING: drivers/net/mlx4/mlx4_core.o(.text+0x728c): Section mismatch in reference from the function .mlx4_init_hca() to the function .devinit.text:.mlx4_load_fw()
The function .mlx4_init_hca() references
the function __devinit .mlx4_load_fw().
This is often because .mlx4_init_hca lacks a __devinit
annotation or the annotation of .mlx4_load_fw is wrong.
WARNING: drivers/net/mlx4/mlx4_core.o(.text+0x7c98): Section mismatch in reference from the function .__mlx4_init_one() to the function .devinit.text:.mlx4_enable_msi_x()
The function .__mlx4_init_one() references
the function __devinit .mlx4_enable_msi_x().
This is often because .__mlx4_init_one lacks a __devinit
annotation or the annotation of .mlx4_enable_msi_x is wrong.
WARNING: drivers/net/mlx4/mlx4_core.o(.text+0x97ac): Section mismatch in reference from the function .mlx4_init_mr_table() to the function .devinit.text:.mlx4_buddy_init()
The function .mlx4_init_mr_table() references
the function __devinit .mlx4_buddy_init().
This is often because .mlx4_init_mr_table lacks a __devinit
annotation or the annotation of .mlx4_buddy_init is wrong.
LD drivers/net/mlx4/built-in.o
WARNING: drivers/net/mlx4/built-in.o(.text+0x6cf8): Section mismatch in reference from the function .mlx4_init_icm() to the function .devinit.text:.mlx4_init_cmpt_table()
The function .mlx4_init_icm() references
the function __devinit .mlx4_init_cmpt_table().
This is often because .mlx4_init_icm lacks a __devinit
annotation or the annotation of .mlx4_init_cmpt_table is wrong.
WARNING: drivers/net/mlx4/built-in.o(.text+0x728c): Section mismatch in reference from the function .mlx4_init_hca() to the function .devinit.text:.mlx4_load_fw()
The function .mlx4_init_hca() references
the function __devinit .mlx4_load_fw().
This is often because .mlx4_init_hca lacks a __devinit
annotation or the annotation of .mlx4_load_fw is wrong.
WARNING: drivers/net/mlx4/built-in.o(.text+0x7c98): Section mismatch in reference from the function .__mlx4_init_one() to the function .devinit.text:.mlx4_enable_msi_x()
The function .__mlx4_init_one() references
the function __devinit .mlx4_enable_msi_x().
This is often because .__mlx4_init_one lacks a __devinit
annotation or the annotation of .mlx4_enable_msi_x is wrong.
WARNING: drivers/net/mlx4/built-in.o(.text+0x97ac): Section mismatch in reference from the function .mlx4_init_mr_table() to the function .devinit.text:.mlx4_buddy_init()
The function .mlx4_init_mr_table() references
the function __devinit .mlx4_buddy_init().
This is often because .mlx4_init_mr_table lacks a __devinit
annotation or the annotation of .mlx4_buddy_init is wrong.
WARNING: drivers/net/tokenring/built-in.o(.text+0x4d64): Section mismatch in reference from the function .olympic_open() to the function .devinit.text:.olympic_init()
The function .olympic_open() references
the function __devinit .olympic_init().
This is often because .olympic_open lacks a __devinit
annotation or the annotation of .olympic_init is wrong.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Stephen Hemminger @ 2008-01-30 16:21 UTC (permalink / raw)
To: Bruce Allen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.63.0801300758020.11487@trinity.phys.uwm.edu>
On Wed, 30 Jan 2008 08:01:46 -0600 (CST)
Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
> Hi David,
>
> Thanks for your note.
>
> >> (The performance of a full duplex stream should be close to 1Gb/s in
> >> both directions.)
> >
> > This is not a reasonable expectation.
> >
> > ACKs take up space on the link in the opposite direction of the
> > transfer.
> >
> > So the link usage in the opposite direction of the transfer is
> > very far from zero.
>
> Indeed, we are not asking to see 1000 Mb/s. We'd be happy to see 900
> Mb/s.
>
> Netperf is trasmitting a large buffer in MTU-sized packets (min 1500
> bytes). Since the acks are only about 60 bytes in size, they should be
> around 4% of the total traffic. Hence we would not expect to see more
> than 960 Mb/s.
>
> We have run these same tests on older kernels (with Broadcomm NICS) and
> gotten above 900 Mb/s full duplex.
>
> Cheers,
> Bru
Don't forget the network overhead: http://sd.wareonearth.com/~phil/net/overhead/
Max TCP Payload data rates over ethernet:
(1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
(1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
I believe what you are seeing is an effect that occurs when using
cubic on links with no other idle traffic. With two flows at high speed,
the first flow consumes most of the router buffer and backs off gradually,
and the second flow is not very aggressive. It has been discussed
back and forth between TCP researchers with no agreement, one side
says that it is unfairness and the other side says it is not a problem in
the real world because of the presence of background traffic.
See:
http://www.hamilton.ie/net/pfldnet2007_cubic_final.pdf
http://www.csc.ncsu.edu/faculty/rhee/Rebuttal-LSM-new.pdf
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
From: Kok, Auke @ 2008-01-30 16:23 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linus Torvalds, Randy Dunlap, Linux Kernel Mailing List,
David S. Miller, akpm, NetDev
In-Reply-To: <47A04C07.1040200@garzik.org>
Jeff Garzik wrote:
> Linus Torvalds wrote:
>>
>> On Tue, 29 Jan 2008, Randy Dunlap wrote:
>>> Andrew was concerned about this when the driver was in -mm.
>>> He asked for a patch that would set E1000E to same value as E1000
>>> and I supplied that. Auke acked it IIRC. Other people vetoed it. :(
>>
>> Yeah, I've been discussing with Jeff and the gang.
>>
>> I think we have agreed on a solution where the ID's show up in the old
>> driver if the new driver is not enabled at all.
>>
>> (And as a side note: it turns out that the problem I experienced
>> didn't come from the new e1000e driver after all, so I'll be removing
>> the EXPERIMENTAL flag again).
>>
>> So I'd suggest the final patch be something like this, but I'm sendign
>> it out just as an example of how we could solve this, not necessarily
>> as a final patch.
>>
>> Jeff, Auke, would something like this be acceptable? It makes it very
>> obvious in the driver table which entries are for the PCIE versions
>> that would be handled by the E1000E driver if it is enabled..
>>
>> Untested, but as mentioned, this is more of a "this looks maintainable
>> and like it should solve the issues" rather than anything I was
>> planning on committing now.
>>
>> Linus
>> ---
>> drivers/net/Kconfig | 5 ++-
>> drivers/net/e1000/e1000_main.c | 60
>> ++++++++++++++++++++++------------------
>> 2 files changed, 37 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>> index 5a2d1dd..6c57540 100644
>> --- a/drivers/net/Kconfig
>> +++ b/drivers/net/Kconfig
>> @@ -1992,7 +1992,7 @@ config E1000_DISABLE_PACKET_SPLIT
>>
>> config E1000E
>> tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
>> - depends on PCI && EXPERIMENTAL
>> + depends on PCI
>> ---help---
>> This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
>> ethernet family of adapters. For PCI or PCI-X e1000 adapters,
>> @@ -2009,6 +2009,9 @@ config E1000E
>> To compile this driver as a module, choose M here. The module
>> will be called e1000e.
>>
>> +config E1000E_ENABLED
>> + def_bool E1000E != n
>> +
>> config IP1000
>> tristate "IP1000 Gigabit Ethernet support"
>> depends on PCI && EXPERIMENTAL
>> diff --git a/drivers/net/e1000/e1000_main.c
>> b/drivers/net/e1000/e1000_main.c
>> index 3111af6..8c87940 100644
>> --- a/drivers/net/e1000/e1000_main.c
>> +++ b/drivers/net/e1000/e1000_main.c
>> @@ -47,6 +47,12 @@ static const char e1000_copyright[] = "Copyright
>> (c) 1999-2006 Intel Corporation
>> * Macro expands to...
>> * {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
>> */
>> +#ifdef CONFIG_E1000E_ENABLED
>> + #define PCIE(x) +#else
>> + #define PCIE(x) x,
>> +#endif
>
> Patch gets my ACK, if you like, though an improvement would be to have
> your Kconfig logic activate CONFIG_E1000_PCIEX. Then future janitors
> could come along and disable unused code in addition to PCI IDs.
Ack from my side as well, allthough I hope that this code will not live long as I
would love to start taking out pci-e code out of e1000. If we merge this patch
then I suggest that we don't do that until for at least a whole cycle, since it
does not make much sense otherwise.
Auke
^ permalink raw reply
* Re: b44 compile failure
From: John W. Linville @ 2008-01-30 16:21 UTC (permalink / raw)
To: maximilian attems; +Cc: zambrano, netdev
In-Reply-To: <20080130105926.GC24152@stro.at>
On Wed, Jan 30, 2008 at 11:59:26AM +0100, maximilian attems wrote:
> drivers/net/b44.c: In function 'b44_remove_one':
> drivers/net/b44.c:2231: error: implicit declaration of function 'ssb_pcihost_set_power_state'
>
> compiles fine on 64 bit x86, but not on 32, see log:
> http://stats.buildserver.net/fetch.php?&pkg=linux-2.6&ver=2.6.24-trunk1%7Esnapshot.10272&arch=i386&stamp=1201665377&file=log&as=raw
It seems to build fine on my i686 box. What dtree are you using?
And what is your .config? Is CONFIG_SSB enabled?
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC/PATCH] e100 driver didn't support any MII-less PHYs...
From: Kok, Auke @ 2008-01-30 16:34 UTC (permalink / raw)
To: andi; +Cc: e1000-devel, netdev, linux-kernel, bunk
In-Reply-To: <20080130064909.GA19793@rhlx01.hs-esslingen.de>
Andreas Mohr wrote:
> Hi,
>
> On Tue, Jan 29, 2008 at 03:09:25PM -0800, Kok, Auke wrote:
>> Andreas Mohr wrote:
>>> Perhaps it's useful to file a bug/patch
>>> on http://sourceforge.net/projects/e1000/ ? Perhaps -mm testing?
>> I wanted to push this though our testing labs first which has not happened due to
>> time constraints - that should quickly at least confirm that the most common nics
>> work OK after the change with your patch. I'll try and see if we can get this
>> testing done soon.
>
> Oh, full-scale regression testing even? Nice idea...
> Would optionally be even better if during hardware tests one could also
> dig out some i82503-based card (or additional MII-less cards?)
> since I didn't really make any effort yet to try to make them all
> recognized/supported by my patch already (would have been out of scope anyway
> since I have this single card only).
the problem is that I think that most of those (mii-less cards) are customly
designed by OEM's that buy the silicon and glue on a different interface and we
usually do not carry those designs in our labs apart from a few exceptions. So, I
can at least touch the common hardware in testing, but not the exotic stuff.
Auke
^ permalink raw reply
* Re: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure (was: Re: fixed phy support (warning related to FIXED_MII_100_FDX))
From: Kumar Gala @ 2008-01-30 16:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev list, netdev, Eugene Konev, Anton Vorontsov
In-Reply-To: <20080121204953.GA11384@localhost.localdomain>
On Jan 21, 2008, at 2:49 PM, Anton Vorontsov wrote:
> On Mon, Jan 21, 2008 at 01:19:41PM -0600, Kumar Gala wrote:
>> Anton,
>>
>> it looks like the "TI AR7 CPMAC Ethernet support" uses FIXED_PHY and
>> was selecting FIXED_MII_100_FDX which is gone.
>>
>> Can you look into this. I get the following warning now:
>>
>> scripts/kconfig/conf -s arch/powerpc/Kconfig
>> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
>> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
>
> Wow. I thought there were no Fixed PHY users. :-)
>
> Jeff, as you've already Acked Fixed PHY rework to go through powerpc
> tree, would you please Ack this patch in addition? I hope cpmac
> maintainer will fix remaining issues as time goes by.
>
> Thanks!
Jeff, just a reminder to look at this.
- k
> - - - -
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
>
> This patch converts cpmac to the new Fixed PHY infrastructure,
> though it
> doesn't fix all the problems with that driver. I didn't even bother to
> test this patch to compile, because cpmac driver is broken in
> several ways:
>
> 1. This driver won't compile by itself because lack of its header
> describing
> platform data;
> 2. It assumes that fixed PHYs should be created by the ethernet
> driver.
> It is wrong assumption: fixed PHYs creation is platform code
> authority,
> driver must blindly accept bus_id and phy_id platform data variables
> instead.
>
> Also, it seem that that driver doesn't have actual in-tree users, so
> nothing to fix further.
>
> The main purpose of that patch is to get rid of the following Kconfig
> warning:
>
> scripts/kconfig/conf -s arch/powerpc/Kconfig
> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/net/Kconfig | 4 +--
> drivers/net/cpmac.c | 55 +++++++++++++++
> +----------------------------------
> 2 files changed, 19 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 114771a..5380ff9 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1707,10 +1707,8 @@ config SC92031
>
> config CPMAC
> tristate "TI AR7 CPMAC Ethernet support (EXPERIMENTAL)"
> - depends on NET_ETHERNET && EXPERIMENTAL && AR7
> + depends on NET_ETHERNET && EXPERIMENTAL && AR7 && BROKEN
> select PHYLIB
> - select FIXED_PHY
> - select FIXED_MII_100_FDX
> help
> TI AR7 CPMAC Ethernet support
>
> diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
> index 6fd95a2..88eeb1d 100644
> --- a/drivers/net/cpmac.c
> +++ b/drivers/net/cpmac.c
> @@ -848,15 +848,6 @@ static void cpmac_adjust_link(struct net_device
> *dev)
> spin_unlock(&priv->lock);
> }
>
> -static int cpmac_link_update(struct net_device *dev,
> - struct fixed_phy_status *status)
> -{
> - status->link = 1;
> - status->speed = 100;
> - status->duplex = 1;
> - return 0;
> -}
> -
> static int cpmac_open(struct net_device *dev)
> {
> int i, size, res;
> @@ -999,11 +990,11 @@ static int external_switch;
> static int __devinit cpmac_probe(struct platform_device *pdev)
> {
> int rc, phy_id, i;
> + int mdio_bus_id = cpmac_mii.id;
> struct resource *mem;
> struct cpmac_priv *priv;
> struct net_device *dev;
> struct plat_cpmac_data *pdata;
> - struct fixed_info *fixed_phy;
> DECLARE_MAC_BUF(mac);
>
> pdata = pdev->dev.platform_data;
> @@ -1017,9 +1008,23 @@ static int __devinit cpmac_probe(struct
> platform_device *pdev)
> }
>
> if (phy_id == PHY_MAX_ADDR) {
> - if (external_switch || dumb_switch)
> + if (external_switch || dumb_switch) {
> + struct fixed_phy_status status = {};
> +
> + mdio_bus_id = 0;
> +
> + /*
> + * FIXME: this should be in the platform code!
> + * Since there is not platform code at all (that is,
> + * no mainline users of that driver), place it here
> + * for now.
> + */
> phy_id = 0;
> - else {
> + status.link = 1;
> + status.duplex = 1;
> + status.speed = 100;
> + fixed_phy_add(PHY_POLL, phy_id, &status);
> + } else {
> printk(KERN_ERR "cpmac: no PHY present\n");
> return -ENODEV;
> }
> @@ -1063,32 +1068,8 @@ static int __devinit cpmac_probe(struct
> platform_device *pdev)
> priv->msg_enable = netif_msg_init(debug_level, 0xff);
> memcpy(dev->dev_addr, pdata->dev_addr, sizeof(dev->dev_addr));
>
> - if (phy_id == 31) {
> - snprintf(priv->phy_name, BUS_ID_SIZE, PHY_ID_FMT, cpmac_mii.id,
> - phy_id);
> - } else {
> - /* Let's try to get a free fixed phy... */
> - for (i = 0; i < MAX_PHY_AMNT; i++) {
> - fixed_phy = fixed_mdio_get_phydev(i);
> - if (!fixed_phy)
> - continue;
> - if (!fixed_phy->phydev->attached_dev) {
> - strncpy(priv->phy_name,
> - fixed_phy->phydev->dev.bus_id,
> - BUS_ID_SIZE);
> - fixed_mdio_set_link_update(fixed_phy->phydev,
> - &cpmac_link_update);
> - goto phy_found;
> - }
> - }
> - if (netif_msg_drv(priv))
> - printk(KERN_ERR "%s: Could not find fixed PHY\n",
> - dev->name);
> - rc = -ENODEV;
> - goto fail;
> - }
> + snprintf(priv->phy_name, BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id,
> phy_id);
>
> -phy_found:
> priv->phy = phy_connect(dev, priv->phy_name, &cpmac_adjust_link, 0,
> PHY_INTERFACE_MODE_MII);
> if (IS_ERR(priv->phy)) {
> --
> 1.5.2.2
^ permalink raw reply
* Re: e1000 performance issue in 4 simultaneous links
From: Kok, Auke @ 2008-01-30 16:57 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: David Miller, benny+usenet, netdev
In-Reply-To: <20080112050841.M73900@visp.net.lb>
Denys Fedoryshchenko wrote:
> Sorry. that i interfere in this subject.
>
> Do you recommend CONFIG_IRQBALANCE to be enabled?
I certainly do not. Manual tweaking and pinning the irq's to the correct CPU will
give the best performance (for specific loads).
The userspace irqbalance daemon tries very hard to approximate this behaviour and
is what I recommend for most situations, it usually does the right thing and does
so without making your head spin (just start it).
The in-kernel one usually does the wrong thing for network loads.
Cheers,
Auke
^ permalink raw reply
* Re: [PATCH] [1/2] Skip empty hash buckets faster in /proc/net/tcp
From: Roland Dreier @ 2008-01-30 17:03 UTC (permalink / raw)
To: Andi Kleen; +Cc: meissner, netdev, davem
In-Reply-To: <20080130901.138686634@suse.de>
> On a 2GB Core2 system here I see a time cat /proc/net/tcp > /dev/null
> constently dropping from 0.44s to 0.4-0.8s system time with this change.
Seems like there must be a typo in either the before or after times
you report here?
^ permalink raw reply
* Re: [BUILD FAILURE] 2.6.24-git7 section type conflict at various drivers on powerpc
From: Sam Ravnborg @ 2008-01-30 17:04 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: LKML, netdev, linuxppc-dev, Andy Whitcroft
In-Reply-To: <47A0A3AF.5050005@linux.vnet.ibm.com>
On Wed, Jan 30, 2008 at 09:49:59PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> Following are the different build failure with 2.6.24-git7 kernel on the powerpc
>
> drivers/net/typhoon.c:181: error: typhoon_card_info causes a section type conflict
> make[2]: *** [drivers/net/typhoon.o] Error 1
>
> drivers/net/natsemi.c:259: error: natsemi_pci_info causes a section type conflict
> make[2]: *** [drivers/net/natsemi.o] Error 1
>
> drivers/net/bnx2.c:95: error: board_info causes a section type conflict
> make[2]: *** [drivers/net/bnx2.o] Error 1
>
> drivers/net/via-velocity.c:454: error: velocity_id_table causes a section type conflict
> make[2]: *** [drivers/net/via-velocity.o] Error 1
A quick look told me that they are all caused by const data
annotated with __devinitdata.
Try replacing all annotations of const variables
from __devinitdata to __devinitconst.
Sam
^ permalink raw reply
* Re: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
From: Jeff Garzik @ 2008-01-30 17:09 UTC (permalink / raw)
To: avorontsov; +Cc: Kumar Gala, linuxppc-dev list, netdev, Eugene Konev
In-Reply-To: <20080121204953.GA11384@localhost.localdomain>
Anton Vorontsov wrote:
> On Mon, Jan 21, 2008 at 01:19:41PM -0600, Kumar Gala wrote:
>> Anton,
>>
>> it looks like the "TI AR7 CPMAC Ethernet support" uses FIXED_PHY and
>> was selecting FIXED_MII_100_FDX which is gone.
>>
>> Can you look into this. I get the following warning now:
>>
>> scripts/kconfig/conf -s arch/powerpc/Kconfig
>> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
>> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
>
> Wow. I thought there were no Fixed PHY users. :-)
>
> Jeff, as you've already Acked Fixed PHY rework to go through powerpc
> tree, would you please Ack this patch in addition? I hope cpmac
> maintainer will fix remaining issues as time goes by.
>
> Thanks!
>
> - - - -
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
>
> This patch converts cpmac to the new Fixed PHY infrastructure, though it
> doesn't fix all the problems with that driver. I didn't even bother to
> test this patch to compile, because cpmac driver is broken in several ways:
>
> 1. This driver won't compile by itself because lack of its header describing
> platform data;
> 2. It assumes that fixed PHYs should be created by the ethernet driver.
> It is wrong assumption: fixed PHYs creation is platform code authority,
> driver must blindly accept bus_id and phy_id platform data variables
> instead.
>
> Also, it seem that that driver doesn't have actual in-tree users, so
> nothing to fix further.
>
> The main purpose of that patch is to get rid of the following Kconfig
> warning:
>
> scripts/kconfig/conf -s arch/powerpc/Kconfig
> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
ACK
^ permalink raw reply
* Re: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
From: Kumar Gala @ 2008-01-30 17:24 UTC (permalink / raw)
To: Jeff Garzik; +Cc: avorontsov, linuxppc-dev list, netdev, Eugene Konev
In-Reply-To: <47A0AF56.3060804@garzik.org>
On Jan 30, 2008, at 11:09 AM, Jeff Garzik wrote:
> Anton Vorontsov wrote:
>> On Mon, Jan 21, 2008 at 01:19:41PM -0600, Kumar Gala wrote:
>>> Anton,
>>>
>>> it looks like the "TI AR7 CPMAC Ethernet support" uses FIXED_PHY
>>> and was selecting FIXED_MII_100_FDX which is gone.
>>>
>>> Can you look into this. I get the following warning now:
>>>
>>> scripts/kconfig/conf -s arch/powerpc/Kconfig
>>> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
>>> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
>> Wow. I thought there were no Fixed PHY users. :-)
>> Jeff, as you've already Acked Fixed PHY rework to go through powerpc
>> tree, would you please Ack this patch in addition? I hope cpmac
>> maintainer will fix remaining issues as time goes by.
>> Thanks!
>> - - - -
>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Subject: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
>> This patch converts cpmac to the new Fixed PHY infrastructure,
>> though it
>> doesn't fix all the problems with that driver. I didn't even bother
>> to
>> test this patch to compile, because cpmac driver is broken in
>> several ways:
>> 1. This driver won't compile by itself because lack of its header
>> describing
>> platform data;
>> 2. It assumes that fixed PHYs should be created by the ethernet
>> driver.
>> It is wrong assumption: fixed PHYs creation is platform code
>> authority,
>> driver must blindly accept bus_id and phy_id platform data
>> variables
>> instead.
>> Also, it seem that that driver doesn't have actual in-tree users, so
>> nothing to fix further.
>> The main purpose of that patch is to get rid of the following Kconfig
>> warning:
>> scripts/kconfig/conf -s arch/powerpc/Kconfig
>> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
>> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> ACK
Is this going through netdev or do you want me to pick it via the
powerpc route?
- k
^ permalink raw reply
* Re: [PATCH] [1/2] Skip empty hash buckets faster in /proc/net/tcp
From: Andi Kleen @ 2008-01-30 17:32 UTC (permalink / raw)
To: Roland Dreier; +Cc: Andi Kleen, meissner, netdev, davem
In-Reply-To: <adasl0fb60b.fsf@cisco.com>
On Wed, Jan 30, 2008 at 09:03:16AM -0800, Roland Dreier wrote:
> > On a 2GB Core2 system here I see a time cat /proc/net/tcp > /dev/null
> > constently dropping from 0.44s to 0.4-0.8s system time with this change.
>
> Seems like there must be a typo in either the before or after times
> you report here?
Yes thanks, it was 0.44s down to 0.04s/0.08s here. Somehow the zeroes
got lost.
-Andi
^ permalink raw reply
* RE: e1000 full-duplex TCP performance well below wire speed
From: Brandeburg, Jesse @ 2008-01-30 17:36 UTC (permalink / raw)
To: Bruce Allen, netdev; +Cc: Carsten Aulbert, Henning Fehrmann, Bruce Allen
In-Reply-To: <Pine.LNX.4.63.0801300621290.6391@trinity.phys.uwm.edu>
Bruce Allen wrote:
> Details:
> Kernel version: 2.6.23.12
> ethernet NIC: Intel 82573L
> ethernet driver: e1000 version 7.3.20-k2
> motherboard: Supermicro PDSML-LN2+ (one quad core Intel Xeon X3220,
> Intel 3000 chipset, 8GB memory)
Hi Bruce,
The 82573L (a client NIC, regardless of the class of machine it is in)
only has a x1 connection which does introduce some latency since the
slot is only capable of about 2Gb/s data total, which includes overhead
of descriptors and other transactions. As you approach the maximum of
the slot it gets more and more difficult to get wire speed in a
bidirectional test.
> The test was done with various mtu sizes ranging from 1500 to 9000,
> with ethernet flow control switched on and off, and using reno and
> cubic as a TCP congestion control.
As asked in LKML thread, please post the exact netperf command used to
start the client/server, whether or not you're using irqbalanced (aka
irqbalance) and what cat /proc/interrupts looks like (you ARE using MSI,
right?)
I've recently discovered that particularly with the most recent kernels
if you specify any socket options (-- -SX -sY) to netperf it does worse
than if it just lets the kernel auto-tune.
> The behavior depends on the setup. In one test we used cubic
> congestion control, flow control off. The transfer rate in one
> direction was above 0.9Gb/s while in the other direction it was 0.6
> to 0.8 Gb/s. After 15-20s the rates flipped. Perhaps the two steams
> are fighting for resources. (The performance of a full duplex stream
> should be close to 1Gb/s in both directions.) A graph of the
> transfer speed as a function of time is here:
> https://n0.aei.uni-hannover.de/networktest/node19-new20-noflow.jpg
> Red shows transmit and green shows receive (please ignore other
> plots):
One other thing you can try with e1000 is disabling the dynamic
interrupt moderation by loading the driver with
InterruptThrottleRate=8000,8000,... (the number of commas depends on
your number of ports) which might help in your particular benchmark.
just for completeness can you post the dump of ethtool -e eth0 and lspci
-vvv?
Thanks,
Jesse
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox