* [2.6 patch] unexport ip6_find_1stfragopt
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Herbert Xu, davem; +Cc: netdev
This patch removes the no longer used
EXPORT_SYMBOL_GPL(ip6_find_1stfragopt).
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
961bcbf7370019e35920a75d2d34c91b71708dfe
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 15c4f6c..ca707c0 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -595,7 +595,6 @@ int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
return offset;
}
-EXPORT_SYMBOL_GPL(ip6_find_1stfragopt);
static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
{
^ permalink raw reply related
* [2.6 patch] unexport sysctl_tcp_tso_win_divisor
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Ilpo Järvinen, David S. Miller; +Cc: netdev
This patch removes the no longer used
EXPORT_SYMBOL(sysctl_tcp_tso_win_divisor).
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
4884e7997ba5f63f2efeaeead21ed2768fb3f4de
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 89f0188..ed750f9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2564,5 +2564,4 @@ EXPORT_SYMBOL(tcp_connect);
EXPORT_SYMBOL(tcp_make_synack);
EXPORT_SYMBOL(tcp_simple_retransmit);
EXPORT_SYMBOL(tcp_sync_mss);
-EXPORT_SYMBOL(sysctl_tcp_tso_win_divisor);
EXPORT_SYMBOL(tcp_mtup_init);
^ permalink raw reply related
* [2.6 patch] net/xfrm/: remove unused exports
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Paul Moore; +Cc: netdev
This patch removes the following no longer used EXPORT_SYMBOL's:
- xfrm_input.c: xfrm_parse_spi
- xfrm_state.c: xfrm_replay_check
- xfrm_state.c: xfrm_replay_advance
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
net/xfrm/xfrm_input.c | 1 -
net/xfrm/xfrm_state.c | 2 --
2 files changed, 3 deletions(-)
03a968fa089d9d1a700875af339b263b6fff4ff3
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 039e701..d32b67a 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -81,7 +81,6 @@ int xfrm_parse_spi(struct sk_buff *skb, u8 nexthdr, __be32 *spi, __be32 *seq)
*seq = *(__be32*)(skb_transport_header(skb) + offset_seq);
return 0;
}
-EXPORT_SYMBOL(xfrm_parse_spi);
int xfrm_prepare_input(struct xfrm_state *x, struct sk_buff *skb)
{
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 3003503..15daed0 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1645,7 +1645,6 @@ err:
xfrm_audit_state_replay(x, skb, net_seq);
return -EINVAL;
}
-EXPORT_SYMBOL(xfrm_replay_check);
void xfrm_replay_advance(struct xfrm_state *x, __be32 net_seq)
{
@@ -1667,7 +1666,6 @@ void xfrm_replay_advance(struct xfrm_state *x, __be32 net_seq)
if (xfrm_aevent_is_on())
xfrm_replay_notify(x, XFRM_REPLAY_UPDATE);
}
-EXPORT_SYMBOL(xfrm_replay_advance);
static LIST_HEAD(xfrm_km_list);
static DEFINE_RWLOCK(xfrm_km_lock);
^ permalink raw reply related
* [2.6 patch] ibmlana_adapter_names[] must be __devinitdata
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
This patch fixes the following section mismatch:
<-- snip -->
...
WARNING: drivers/net/built-in.o(.devinit.text+0x1baa4): Section mismatch in reference from the function ibmlana_init_one() to the variable .init.data:ibmlana_adapter_names
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
50492d4a3ae5358858e6db3572370fb874203074
diff --git a/drivers/net/ibmlana.c b/drivers/net/ibmlana.c
index 4ccc1cd..95e3464 100644
--- a/drivers/net/ibmlana.c
+++ b/drivers/net/ibmlana.c
@@ -901,7 +901,7 @@ static short ibmlana_adapter_ids[] __initdata = {
0x0000
};
-static char *ibmlana_adapter_names[] __initdata = {
+static char *ibmlana_adapter_names[] __devinitdata = {
"IBM LAN Adapter/A",
NULL
};
^ permalink raw reply related
* [2.6 patch] ibmlana_init_one() must be __devinit
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
This patch fixes the following section mismatch:
<-- snip -->
...
WARNING: drivers/net/built-in.o(.text+0x1148a5): Section mismatch in reference from the function ibmlana_init_one() to the variable .init.data:ibmlana_adapter_names
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
ec20d90864ce5b935b10bb9190be09686aa94904
diff --git a/drivers/net/ibmlana.c b/drivers/net/ibmlana.c
index 46e2c52..4ccc1cd 100644
--- a/drivers/net/ibmlana.c
+++ b/drivers/net/ibmlana.c
@@ -906,7 +906,7 @@ static char *ibmlana_adapter_names[] __initdata = {
NULL
};
-static int ibmlana_init_one(struct device *kdev)
+static int __devinit ibmlana_init_one(struct device *kdev)
{
struct mca_device *mdev = to_mca_device(kdev);
struct net_device *dev;
^ permalink raw reply related
* [2.6 patch] olympic_open() must be __devinit
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: p2, mikep, jgarzik; +Cc: netdev
This patch fixes the following section mismatch:
<-- snip -->
...
WARNING: drivers/net/built-in.o(.text+0x155573): Section mismatch in reference from the function olympic_open() to the function .devinit.text:olympic_init()
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
fd1e6e0bb5b17dc85cd24d6263e8751e816f59e6
diff --git a/drivers/net/tokenring/olympic.c b/drivers/net/tokenring/olympic.c
index e7b4adc..433c994 100644
--- a/drivers/net/tokenring/olympic.c
+++ b/drivers/net/tokenring/olympic.c
@@ -434,7 +434,7 @@ static int __devinit olympic_init(struct net_device *dev)
}
-static int olympic_open(struct net_device *dev)
+static int __devinit olympic_open(struct net_device *dev)
{
struct olympic_private *olympic_priv=netdev_priv(dev);
u8 __iomem *olympic_mmio=olympic_priv->olympic_mmio,*init_srb;
^ permalink raw reply related
* [2.6 patch] via-rhine.c:rhine_hw_init() must be __devinit
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: rl, jgarzik; +Cc: netdev, linux-kernel
Thie patch fixes the following section mismatch:
<-- snip -->
...
WARNING: drivers/net/built-in.o(.text+0xdd840): Section mismatch in reference from the function rhine_hw_init() to the function .devinit.text:rhine_reload_eeprom()
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
a79db62b73dab2b71fa2f47398fd39364d7aae31
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index 87c180b..7c851b1 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -606,7 +606,7 @@ static int rhine_napipoll(struct napi_struct *napi, int budget)
}
#endif
-static void rhine_hw_init(struct net_device *dev, long pioaddr)
+static void __devinit rhine_hw_init(struct net_device *dev, long pioaddr)
{
struct rhine_private *rp = netdev_priv(dev);
^ permalink raw reply related
* Re: [PATCH] [1/1] Deprecate tcp_tw_{reuse,recycle}
From: Ben Greear @ 2008-01-30 19:22 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <20080130938.523292915@suse.de>
Andi Kleen wrote:
> We've recently had a long discussion about the CVE-2005-0356 time stamp denial-of-service
> attack. It turned out that Linux is only vunerable to this problem when tcp_tw_recycle
> is enabled (which it is not by default).
>
> In general these two options are not really usable in today's internet because they
> make the (often false) assumption that a single IP address has a single TCP time stamp /
> PAWS clock. This assumption breaks both NAT/masquerading and also opens Linux to denial
> of service attacks (see the CVE description)
>
> Due to these numerous problems I propose to remove this code for 2.6.26
We use these features to enable creating very high numbers of short-lived
TCP connections, primarily used as a test tool for other network
devices.
Perhaps just document the adverse affects and/or have it print out a warning
on the console whenever the feature is enabled?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: net-2.6.25 is no more...
From: Daniel Lezcano @ 2008-01-30 19:16 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Daniel Lezcano, David Miller, netdev
In-Reply-To: <20080130182918.GC1819@ghostprotocols.net>
Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 30, 2008 at 06:38:53PM +0100, Daniel Lezcano escreveu:
>> David Miller wrote:
>>> 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.
>> What will happen to the patches sent to net-2.6.25 a few days ago during
>> the merge ? Should I resend them against net-2.6 ?
>
> They are probably in net-2.6 already, have you checked? I checked and a
> fix I sent that was not yet merged by Linus is there, in net-2.6.
I checked net-2.6, but unfortunately they are not in. I sent two
compilation fix error and a subset of the netns ipv6 routing.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Ben Greear @ 2008-01-30 19:17 UTC (permalink / raw)
To: Bruce Allen; +Cc: netdev, Carsten Aulbert, Henning Fehrmann, Bruce Allen
In-Reply-To: <Pine.LNX.4.63.0801300621290.6391@trinity.phys.uwm.edu>
Bruce Allen wrote:
> (Pádraig Brady has suggested that I post this to Netdev. It was
> originally posted to LKML here: http://lkml.org/lkml/2008/1/30/141 )
>
>
> Dear NetDev,
>
> We've connected a pair of modern high-performance boxes with integrated
> copper Gb/s Intel NICS, with an ethernet crossover cable, and have run
> some netperf full duplex TCP tests. The transfer rates are well below
> wire speed. We're reporting this as a kernel bug, because we expect a
> vanilla kernel with default settings to give wire speed (or close to
> wire speed) performance in this case. We DO see wire speed in simplex
> transfers. The behavior has been verified on multiple machines with
> identical hardware.
Try using NICs in the pci-e slots. We have better
luck there, as you usually have more lanes and/or higher
quality NIC chipsets available in this case.
Try a UDP test to make sure the NIC can actually handle the throughput.
Look at the actual link usage as reported by the ethernet driver so that you
take all of the ACKS and other overhead into account.
Try the same test using 10G hardware (CX4 NICs are quite affordable
these days, and we drove a 2-port 10G NIC based on the Intel ixgbe
chipset at around 4Gbps on two ports, full duplex, using pktgen).
As in around 16Gbps throughput across the busses. That may also give you an idea
if the bottleneck is hardware or software related.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [drivers/net/bnx2.c] ADVERTISE_1000XPSE_ASYM
From: Michael Chan @ 2008-01-30 18:51 UTC (permalink / raw)
To: Roel Kluin, davem; +Cc: lkml, netdev
In-Reply-To: <47A084B0.1000301@tiscali.nl>
On Wed, 2008-01-30 at 15:07 +0100, Roel Kluin wrote:
> 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?
>
Thanks for catching this. The patch below will fix it.
[BNX2]: Fix ASYM PAUSE advertisement for remote PHY.
We were checking for the ASYM_PAUSE bit for 1000Base-X twice instead
checking for both the 1000Base-X bit and the 10/100/1000Base-T bit.
The purpose of the logic is to tell the firmware that ASYM_PAUSE is
set on either the Serdes or Copper interface.
Problem was discovered by Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index be7e8f8..77400ad 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1429,7 +1429,7 @@ bnx2_setup_remote_phy(struct bnx2 *bp, u8 port)
if (pause_adv & (ADVERTISE_1000XPAUSE | ADVERTISE_PAUSE_CAP))
speed_arg |= BNX2_NETLINK_SET_LINK_FC_SYM_PAUSE;
- if (pause_adv & (ADVERTISE_1000XPSE_ASYM | ADVERTISE_1000XPSE_ASYM))
+ if (pause_adv & (ADVERTISE_1000XPSE_ASYM | ADVERTISE_PAUSE_ASYM))
speed_arg |= BNX2_NETLINK_SET_LINK_FC_ASYM_PAUSE;
if (port == PORT_TP)
^ permalink raw reply related
* Re: e1000 full-duplex TCP performance well below wire speed
From: Rick Jones @ 2008-01-30 18:45 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: Bruce Allen, netdev, Carsten Aulbert, Henning Fehrmann,
Bruce Allen
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F52044F81DF@orsmsx418.amr.corp.intel.com>
> 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?)
In particular, it would be good to know if you are doing two concurrent
streams, or if you are using the "burst mode" TCP_RR with large
request/response sizes method which then is only using one connection.
> 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.
That is the bit where explicit setsockopts are capped by core [rw]mem
sysctls but the autotuning is not correct?
rick jones
BTW, a bit of netperf news - the "omni" (two routines to measure it all)
tests seem to be more or less working now in top of trunk netperf. It
of course still needs work/polish, but if folks would like to play with
them, I'd love the feedback. Output is a bit different from classic
netperf, and includes an option to emit the results as csv
(test-specific -o presently) rather than "human readable" (test-specific
-O). You get the omni stuff via ./configure --enable-omni and use
"omni" as the test name. No docs yet, for options and their effects,
you need to look at scan_omni_args in src/nettest_omni.c
One other addition in the omni tests is retreiving not just the initial
SO_*BUF sizes, but also the final SO_*BUF sizes so one can see where
autotuning took things just based on netperf output.
If the general concensus is that the overhead of the omni stuff isn't
too dear, (there are more conditionals in the mainline than with classic
netperf) I will convert the classic netperf tests to use the omni code.
BTW, don't have a heart attack when you see the quantity of current csv
output - I do plan on being able to let the user specify what values
should be included :)
^ permalink raw reply
* Re: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
From: Kumar Gala @ 2008-01-30 18:36 UTC (permalink / raw)
To: Jeff Garzik; +Cc: avorontsov, linuxppc-dev list, netdev, Eugene Konev
In-Reply-To: <47A0B6A6.5080903@garzik.org>
>>> Is this going through netdev or do you want me to pick it via the
>>> powerpc route?
>
> Based on your comments I sorta assumed it was most convenient to
> lump in with the rest of the powerpc changes...
That's fine. I'll push it via the powerpc trees.
- k
^ permalink raw reply
* Re: net-2.6.25 is no more...
From: Arnaldo Carvalho de Melo @ 2008-01-30 18:29 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: David Miller, netdev
In-Reply-To: <47A0B62D.3080005@fr.ibm.com>
Em Wed, Jan 30, 2008 at 06:38:53PM +0100, Daniel Lezcano escreveu:
> David Miller wrote:
>> 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.
>
> What will happen to the patches sent to net-2.6.25 a few days ago during
> the merge ? Should I resend them against net-2.6 ?
They are probably in net-2.6 already, have you checked? I checked and a
fix I sent that was not yet merged by Linus is there, in net-2.6.
- Arnaldo
^ permalink raw reply
* Re: b44 compile failure
From: maximilian attems @ 2008-01-30 18:20 UTC (permalink / raw)
To: John W. Linville; +Cc: zambrano, netdev
In-Reply-To: <20080130162157.GC3317@tuxdriver.com>
On Wed, 30 Jan 2008, John W. Linville wrote:
> 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?
don't see any CONFIG_SSB above.
strange can't reprodcue neither, so forget for now.
thanks
^ permalink raw reply
* Strange commit 42a73808ed4f30b739eb52bcbb33a02fe62ceef5
From: Adrian Bunk @ 2008-01-30 17:55 UTC (permalink / raw)
To: Pavel Emelyanov, David S. Miller; +Cc: netdev, linux-kernel
Commit 42a73808ed4f30b739eb52bcbb33a02fe62ceef5
("[RAW]: Consolidate proc interface.") did not only change raw6_seq_ops
(including adding 3 EXPORT_SYMBOL_GPL's to net/ipv4/raw.c for accessing
functions from there), it also removed the only user of raw6_seq_ops...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: net-2.6.25 is no more...
From: Daniel Lezcano @ 2008-01-30 17:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080130.054807.182676684.davem@davemloft.net>
David Miller wrote:
> 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.
What will happen to the patches sent to net-2.6.25 a few days ago during
the merge ? Should I resend them against net-2.6 ?
^ permalink raw reply
* Re: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
From: Jeff Garzik @ 2008-01-30 17:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: avorontsov, linuxppc-dev list, netdev, Eugene Konev
In-Reply-To: <02FAED2A-1154-4D8B-A245-4693BF283515@kernel.crashing.org>
Kumar Gala wrote:
>
> 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?
Based on your comments I sorta assumed it was most convenient to lump in
with the rest of the powerpc changes...
Jeff
^ 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
* 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: [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] [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: [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] [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: 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
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