Netdev List
 help / color / mirror / Atom feed
* [2.6 patch] rtnetlink.c: #if 0 no longer used functions
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
  To: Patrick McHardy, David S. Miller; +Cc: netdev

This patch #if 0's the following no longer used functions:
- rtattr_parse()
- rtattr_strlcpy()
- __rtattr_parse_nested_compat()

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---

 include/linux/rtnetlink.h |   12 ------------
 net/core/rtnetlink.c      |    9 ++++++---
 2 files changed, 6 insertions(+), 15 deletions(-)

06cd9ace5f9ca3d8070364d33ca76d1fa4cd203b 
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index b014f6b..b9e1740 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -602,24 +602,12 @@ struct tcamsg
 
 #include <linux/mutex.h>
 
-extern size_t rtattr_strlcpy(char *dest, const struct rtattr *rta, size_t size);
 static __inline__ int rtattr_strcmp(const struct rtattr *rta, const char *str)
 {
 	int len = strlen(str) + 1;
 	return len > rta->rta_len || memcmp(RTA_DATA(rta), str, len);
 }
 
-extern int rtattr_parse(struct rtattr *tb[], int maxattr, struct rtattr *rta, int len);
-extern int __rtattr_parse_nested_compat(struct rtattr *tb[], int maxattr,
-				        struct rtattr *rta, int len);
-
-#define rtattr_parse_nested(tb, max, rta) \
-	rtattr_parse((tb), (max), RTA_DATA((rta)), RTA_PAYLOAD((rta)))
-
-#define rtattr_parse_nested_compat(tb, max, rta, data, len) \
-({	data = RTA_PAYLOAD(rta) >= len ? RTA_DATA(rta) : NULL; \
-	__rtattr_parse_nested_compat(tb, max, rta, len); })
-
 extern int rtnetlink_send(struct sk_buff *skb, struct net *net, u32 pid, u32 group, int echo);
 extern int rtnl_unicast(struct sk_buff *skb, struct net *net, u32 pid);
 extern int rtnl_notify(struct sk_buff *skb, struct net *net, u32 pid, u32 group,
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ddbdde8..a689f17 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -82,6 +82,8 @@ int rtnl_trylock(void)
 	return mutex_trylock(&rtnl_mutex);
 }
 
+#if 0
+
 int rtattr_parse(struct rtattr *tb[], int maxattr, struct rtattr *rta, int len)
 {
 	memset(tb, 0, sizeof(struct rtattr*)*maxattr);
@@ -108,6 +110,8 @@ int __rtattr_parse_nested_compat(struct rtattr *tb[], int maxattr,
 	return 0;
 }
 
+#endif  /*  0  */
+
 static struct rtnl_link *rtnl_msg_handlers[NPROTO];
 
 static inline int rtm_msgindex(int msgtype)
@@ -442,6 +446,7 @@ void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const void *data
 	memset(RTA_DATA(rta) + attrlen, 0, RTA_ALIGN(size) - size);
 }
 
+#if 0
 size_t rtattr_strlcpy(char *dest, const struct rtattr *rta, size_t size)
 {
 	size_t ret = RTA_PAYLOAD(rta);
@@ -456,6 +461,7 @@ size_t rtattr_strlcpy(char *dest, const struct rtattr *rta, size_t size)
 	}
 	return ret;
 }
+#endif  /*  0  */
 
 int rtnetlink_send(struct sk_buff *skb, struct net *net, u32 pid, unsigned group, int echo)
 {
@@ -1411,9 +1417,6 @@ void __init rtnetlink_init(void)
 }
 
 EXPORT_SYMBOL(__rta_fill);
-EXPORT_SYMBOL(rtattr_strlcpy);
-EXPORT_SYMBOL(rtattr_parse);
-EXPORT_SYMBOL(__rtattr_parse_nested_compat);
 EXPORT_SYMBOL(rtnetlink_put_metrics);
 EXPORT_SYMBOL(rtnl_lock);
 EXPORT_SYMBOL(rtnl_trylock);


^ permalink raw reply related

* [2.6 patch] make struct ipv4_devconf static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
  To: Pavel Emelyanov, David S. Miller; +Cc: netdev, linux-kernel

struct ipv4_devconf can now become static.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---

 include/linux/inetdevice.h |    2 --
 net/ipv4/devinet.c         |    2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

20262a3317069b1bdbf2b37f4002fa5322445914 
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 8d9eaae..fc4e3db 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -17,8 +17,6 @@ struct ipv4_devconf
 	DECLARE_BITMAP(state, __NET_IPV4_CONF_MAX - 1);
 };
 
-extern struct ipv4_devconf ipv4_devconf;
-
 struct in_device
 {
 	struct net_device	*dev;
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 21f71bf..5ab5acc 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -64,7 +64,7 @@
 #include <net/rtnetlink.h>
 #include <net/net_namespace.h>
 
-struct ipv4_devconf ipv4_devconf = {
+static struct ipv4_devconf ipv4_devconf = {
 	.data = {
 		[NET_IPV4_CONF_ACCEPT_REDIRECTS - 1] = 1,
 		[NET_IPV4_CONF_SEND_REDIRECTS - 1] = 1,


^ permalink raw reply related

* [2.6 patch] make net/802/tr.c:sysctl_tr_rif_timeout static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
  To: Pavel Emelyanov, David S. Miller; +Cc: netdev, linux-kernel

sysctl_tr_rif_timeout can now become static.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
e5accd81b924224d40a3f38204c08cf6896ed79b 
diff --git a/net/802/tr.c b/net/802/tr.c
index 3f16b17..18c6647 100644
--- a/net/802/tr.c
+++ b/net/802/tr.c
@@ -76,7 +76,7 @@ static DEFINE_SPINLOCK(rif_lock);
 
 static struct timer_list rif_timer;
 
-int sysctl_tr_rif_timeout = 60*10*HZ;
+static int sysctl_tr_rif_timeout = 60*10*HZ;
 
 static inline unsigned long rif_hash(const unsigned char *addr)
 {


^ permalink raw reply related

* [2.6 patch] make e1000_dump_eeprom() static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
  To: Auke Kok, Jeff Garzik, jesse.brandeburg, jeffrey.t.kirsher,
	john.ronciak
  Cc: e1000-devel, netdev, linux-kernel

This patch makes the needlessly global e1000_dump_eeprom() static.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
b5fd924a1388d4aaa94cf05e42e317c2b1fb5748 
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 7f5b2ae..8a6645b 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -820,7 +820,7 @@ e1000_reset(struct e1000_adapter *adapter)
 /**
  *  Dump the eeprom for users having checksum issues
  **/
-void e1000_dump_eeprom(struct e1000_adapter *adapter)
+static void e1000_dump_eeprom(struct e1000_adapter *adapter)
 {
 	struct net_device *netdev = adapter->netdev;
 	struct ethtool_eeprom eeprom;


^ permalink raw reply related

* [2.6 patch] make s2io.c:init_tti() static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
  To: Surjit Reang, Sreenivasa Honnur, Ramkrishna Vepa,
	santosh.rastapur, sivakumar.subrama
  Cc: netdev, linux-kernel

This patch makes the needlessly global init_tti() static.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
1e8c2b07be955b181814e4c24366517a66557908 
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 5fab7d7..bc94e84 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -1088,7 +1088,7 @@ static int s2io_print_pci_mode(struct s2io_nic *nic)
  *  '-1' on failure
  */
 
-int init_tti(struct s2io_nic *nic, int link)
+static int init_tti(struct s2io_nic *nic, int link)
 {
 	struct XENA_dev_config __iomem *bar0 = nic->bar0;
 	register u64 val64 = 0;


^ permalink raw reply related

* [2.6 patch] IBMLANA no longer has to depend on MCA_LEGACY
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev, linux-kernel

This patch removes the no longer required dependency of IBMLANA
on MCA_LEGACY.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
d83989118e59f403200ea9c71d2293337b49df01 
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index af40ff4..578ae2c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1199,7 +1199,7 @@ config NE2_MCA
 
 config IBMLANA
 	tristate "IBM LAN Adapter/A support"
-	depends on MCA && MCA_LEGACY
+	depends on MCA
 	---help---
 	  This is a Micro Channel Ethernet adapter.  You need to set
 	  CONFIG_MCA to use this driver.  It is both available as an in-kernel


^ permalink raw reply related

* [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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox