Netdev List
 help / color / mirror / Atom feed
* [PATCH 1/2] bridge: Fix MLD queries' ethernet source address
From: Linus Lüssing @ 2011-02-17 18:17 UTC (permalink / raw)
  To: Stephen Hemminger, David S. Miller, bridge
  Cc: netdev, linux-kernel, Herbert Xu, YOSHIFUJI Hideaki,
	Linus Lüssing
In-Reply-To: <20110215154128.2a28632c@nehalam>

Map the IPv6 header's destination multicast address to an ethernet
source address instead of the MLD queries multicast address.

For instance for a general MLD query (multicast address in the MLD query
set to ::), this would wrongly be mapped to 33:33:00:00:00:00, although
an MLD queries destination MAC should always be 33:33:00:00:00:01 which
matches the IPv6 header's multicast destination ff02::1.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
---
 net/bridge/br_multicast.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b5eb28a..f904a2e 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -435,7 +435,6 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
 	eth = eth_hdr(skb);
 
 	memcpy(eth->h_source, br->dev->dev_addr, 6);
-	ipv6_eth_mc_map(group, eth->h_dest);
 	eth->h_proto = htons(ETH_P_IPV6);
 	skb_put(skb, sizeof(*eth));
 
@@ -449,6 +448,7 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
 	ip6h->hop_limit = 1;
 	ipv6_addr_set(&ip6h->saddr, 0, 0, 0, 0);
 	ipv6_addr_set(&ip6h->daddr, htonl(0xff020000), 0, 0, htonl(1));
+	ipv6_eth_mc_map(&ip6h->daddr, eth->h_dest);
 
 	hopopt = (u8 *)(ip6h + 1);
 	hopopt[0] = IPPROTO_ICMPV6;		/* next hdr */
-- 
1.7.2.3


^ permalink raw reply related

* [PATCH 2/2] bridge: Use IPv6 link-local address for multicast listener queries
From: Linus Lüssing @ 2011-02-17 18:17 UTC (permalink / raw)
  To: Stephen Hemminger, David S. Miller, bridge
  Cc: netdev, linux-kernel, Herbert Xu, YOSHIFUJI Hideaki,
	Linus Lüssing
In-Reply-To: <20110215154128.2a28632c@nehalam>

Currently the bridge multicast snooping feature periodically issues
IPv6 general multicast listener queries to sense the absence of a
listener.

For this, it uses :: as its source address - however RFC 2710 requires:
"To be valid, the Query message MUST come from a link-local IPv6 Source
Address". Current Linux kernel versions seem to follow this requirement
and ignore our bogus MLD queries.

With this commit a link local address from the bridge interface is being
used to issue the MLD query, resulting in other Linux devices which are
multicast listeners in the network to respond with a MLD response (which
was not the case before).

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
---
 net/bridge/br_multicast.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f904a2e..2d88861 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -446,7 +446,8 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
 	ip6h->payload_len = htons(8 + sizeof(*mldq));
 	ip6h->nexthdr = IPPROTO_HOPOPTS;
 	ip6h->hop_limit = 1;
-	ipv6_addr_set(&ip6h->saddr, 0, 0, 0, 0);
+	ipv6_dev_get_saddr(dev_net(br->dev), br->dev, &ip6h->daddr, 0,
+			   &ip6h->saddr);
 	ipv6_addr_set(&ip6h->daddr, htonl(0xff020000), 0, 0, htonl(1));
 	ipv6_eth_mc_map(&ip6h->daddr, eth->h_dest);
 
-- 
1.7.2.3


^ permalink raw reply related

* [net-next-2.6 PATCH 0/3] enic: updates to version 2.1.1.9
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
  To: davem; +Cc: netdev

The following series implements enic driver updates:

1/3 - Bug fix: Reset driver count of registered unicast addresses to zero during device reset
2/3 - Clean up: Remove a not needed #ifdef
3/3 - Always use single transmit and single receive hardware queues per device

Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>

^ permalink raw reply

* [net-next-2.6 PATCH 1/3] enic: Bug fix: Reset driver count of registered unicast addresses to zero during device reset
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <20110217185245.2476.60944.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>

During a device reset, clear the counter for the no. of unicast addresses registered.
Also, rename the routines that update unicast and multicast address lists.

Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
 drivers/net/enic/enic.h      |    2 +-
 drivers/net/enic/enic_main.c |   13 +++++++------
 2 files changed, 8 insertions(+), 7 deletions(-)


diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 57fcaee..5f4eb45 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
 
 #define DRV_NAME		"enic"
 #define DRV_DESCRIPTION		"Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION		"2.1.1.6"
+#define DRV_VERSION		"2.1.1.7"
 #define DRV_COPYRIGHT		"Copyright 2008-2011 Cisco Systems, Inc"
 
 #define ENIC_BARS_MAX		6
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 0c24370..a625a0e 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -874,9 +874,10 @@ static struct net_device_stats *enic_get_stats(struct net_device *netdev)
 	return net_stats;
 }
 
-static void enic_reset_multicast_list(struct enic *enic)
+static void enic_reset_addr_lists(struct enic *enic)
 {
 	enic->mc_count = 0;
+	enic->uc_count = 0;
 	enic->flags = 0;
 }
 
@@ -941,7 +942,7 @@ static int enic_set_mac_address(struct net_device *netdev, void *p)
 	return enic_dev_add_station_addr(enic);
 }
 
-static void enic_add_multicast_addr_list(struct enic *enic)
+static void enic_update_multicast_addr_list(struct enic *enic)
 {
 	struct net_device *netdev = enic->netdev;
 	struct netdev_hw_addr *ha;
@@ -996,7 +997,7 @@ static void enic_add_multicast_addr_list(struct enic *enic)
 	enic->mc_count = mc_count;
 }
 
-static void enic_add_unicast_addr_list(struct enic *enic)
+static void enic_update_unicast_addr_list(struct enic *enic)
 {
 	struct net_device *netdev = enic->netdev;
 	struct netdev_hw_addr *ha;
@@ -1073,9 +1074,9 @@ static void enic_set_rx_mode(struct net_device *netdev)
 	}
 
 	if (!promisc) {
-		enic_add_unicast_addr_list(enic);
+		enic_update_unicast_addr_list(enic);
 		if (!allmulti)
-			enic_add_multicast_addr_list(enic);
+			enic_update_multicast_addr_list(enic);
 	}
 }
 
@@ -2067,7 +2068,7 @@ static void enic_reset(struct work_struct *work)
 	enic_dev_hang_notify(enic);
 	enic_stop(enic->netdev);
 	enic_dev_hang_reset(enic);
-	enic_reset_multicast_list(enic);
+	enic_reset_addr_lists(enic);
 	enic_init_vnic_resources(enic);
 	enic_set_rss_nic_cfg(enic);
 	enic_dev_set_ig_vlan_rewrite_mode(enic);


^ permalink raw reply related

* [net-next-2.6 PATCH 2/3] enic: Clean up: Remove a not needed #ifdef
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <20110217185245.2476.60944.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>



Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
 drivers/net/enic/enic.h      |    2 +-
 drivers/net/enic/enic_main.c |    2 --
 2 files changed, 1 insertions(+), 3 deletions(-)


diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 5f4eb45..2ac891b 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
 
 #define DRV_NAME		"enic"
 #define DRV_DESCRIPTION		"Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION		"2.1.1.7"
+#define DRV_VERSION		"2.1.1.8"
 #define DRV_COPYRIGHT		"Copyright 2008-2011 Cisco Systems, Inc"
 
 #define ENIC_BARS_MAX		6
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index a625a0e..d1aa807 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -2223,9 +2223,7 @@ static const struct net_device_ops enic_netdev_dynamic_ops = {
 	.ndo_tx_timeout		= enic_tx_timeout,
 	.ndo_set_vf_port	= enic_set_vf_port,
 	.ndo_get_vf_port	= enic_get_vf_port,
-#ifdef IFLA_VF_MAX
 	.ndo_set_vf_mac		= enic_set_vf_mac,
-#endif
 #ifdef CONFIG_NET_POLL_CONTROLLER
 	.ndo_poll_controller	= enic_poll_controller,
 #endif


^ permalink raw reply related

* [net-next-2.6 PATCH 3/3] enic: Always use single transmit and single receive hardware queues per device
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
  To: davem; +Cc: netdev
In-Reply-To: <20110217185245.2476.60944.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>



Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
 drivers/net/enic/enic.h      |    6 +++---
 drivers/net/enic/enic_main.c |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)


diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 2ac891b..aee5256 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,13 +32,13 @@
 
 #define DRV_NAME		"enic"
 #define DRV_DESCRIPTION		"Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION		"2.1.1.8"
+#define DRV_VERSION		"2.1.1.9"
 #define DRV_COPYRIGHT		"Copyright 2008-2011 Cisco Systems, Inc"
 
 #define ENIC_BARS_MAX		6
 
-#define ENIC_WQ_MAX		8
-#define ENIC_RQ_MAX		8
+#define ENIC_WQ_MAX		1
+#define ENIC_RQ_MAX		1
 #define ENIC_CQ_MAX		(ENIC_WQ_MAX + ENIC_RQ_MAX)
 #define ENIC_INTR_MAX		(ENIC_CQ_MAX + 2)
 
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index d1aa807..4f1710e 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -2080,7 +2080,7 @@ static void enic_reset(struct work_struct *work)
 static int enic_set_intr_mode(struct enic *enic)
 {
 	unsigned int n = min_t(unsigned int, enic->rq_count, ENIC_RQ_MAX);
-	unsigned int m = 1;
+	unsigned int m = min_t(unsigned int, enic->wq_count, ENIC_WQ_MAX);
 	unsigned int i;
 
 	/* Set interrupt mode (INTx, MSI, MSI-X) depending


^ permalink raw reply related

* Re: any way to reset all marked connections when using CONNMARK?
From: Chris Friesen @ 2011-02-17 18:58 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Andrew Beverley, netdev, netfilter-devel, netfilter
In-Reply-To: <alpine.LNX.2.01.1102152342380.18599@obet.zrqbmnf.qr>

On 02/15/2011 04:42 PM, Jan Engelhardt wrote:
> On Tuesday 2011-02-15 23:06, Chris Friesen wrote:

>> For some reason the online man pages for conntrack don't seem to be up
>> to date...they don't have the -U option.  It's listed in the package
>> itself though.
> 
> What online manpages are you referring to?

The first google result for "man conntrack" is

http://linux.die.net/man/8/conntrack

which appears out of date.  The second google result appears okay.

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com

^ permalink raw reply

* [PATCH ethtool] ethtool: Warn if we cannot set the advertising mask for specified speed/duplex
From: Ben Hutchings @ 2011-02-17 19:06 UTC (permalink / raw)
  To: netdev; +Cc: linux-net-drivers, Naveen Chouksey

When autonegotiation is enabled, drivers must determine link speed and
duplex through the autonegotiation process and will generally ignore
the speed and duplex specified in struct ethtool_cmd.  If the user
specifies a recognised combination of speed and duplex, we set the
advertising mask to include only the matching mode.  Otherwise, we
advertise all supported modes.  We should really limit the advertised
modes separately by speed and duplex, but for now we just warn.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This is a longstanding bug in ethtool which people keep getting bitten
by.  Naveen was just the latest to report it.  I have been working on
some changes to improve link advertising and reporting, but until those
are ready I'm adding this warning.

Ben.

 ethtool.c |   46 ++++++++++++++++++++++++++++++++--------------
 1 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/ethtool.c b/ethtool.c
index 1afdfe4..a5c70d5 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1126,7 +1126,7 @@ static void parse_cmdline(int argc, char **argp)
 		}
 	}
 
-	if ((autoneg_wanted == AUTONEG_ENABLE) && (advertising_wanted < 0)) {
+	if (advertising_wanted < 0) {
 		if (speed_wanted == SPEED_10 && duplex_wanted == DUPLEX_HALF)
 			advertising_wanted = ADVERTISED_10baseT_Half;
 		else if (speed_wanted == SPEED_10 &&
@@ -2528,19 +2528,37 @@ static int do_sset(int fd, struct ifreq *ifr)
 				ecmd.phy_address = phyad_wanted;
 			if (xcvr_wanted != -1)
 				ecmd.transceiver = xcvr_wanted;
-			if (advertising_wanted != -1) {
-				if (advertising_wanted == 0)
-					ecmd.advertising = ecmd.supported &
-						(ADVERTISED_10baseT_Half |
-						 ADVERTISED_10baseT_Full |
-						 ADVERTISED_100baseT_Half |
-						 ADVERTISED_100baseT_Full |
-						 ADVERTISED_1000baseT_Half |
-						 ADVERTISED_1000baseT_Full |
-						 ADVERTISED_2500baseX_Full |
-						 ADVERTISED_10000baseT_Full);
-				else
-					ecmd.advertising = advertising_wanted;
+			if (advertising_wanted == 0) {
+				/* XXX If autoneg is on and the user
+				 * specified speed or duplex then we
+				 * should mask the advertised modes
+				 * accordingly.  For now, warn that we
+				 * aren't doing that.
+				 */
+				if (ecmd.autoneg &&
+				    (speed_wanted >= 0 || duplex_wanted >= 0)) {
+					fprintf(stderr, "Cannot advertise");
+					if (speed_wanted >= 0)
+						fprintf(stderr, " speed %d",
+							speed_wanted);
+					if (duplex_wanted >= 0)
+						fprintf(stderr, " duplex %s",
+							duplex_wanted ? 
+							"full" : "half");
+					fprintf(stderr,	"; advertising all"
+						" supported modes\n");
+				}
+				ecmd.advertising = ecmd.supported &
+					(ADVERTISED_10baseT_Half |
+					 ADVERTISED_10baseT_Full |
+					 ADVERTISED_100baseT_Half |
+					 ADVERTISED_100baseT_Full |
+					 ADVERTISED_1000baseT_Half |
+					 ADVERTISED_1000baseT_Full |
+					 ADVERTISED_2500baseX_Full |
+					 ADVERTISED_10000baseT_Full);
+			} else if (advertising_wanted != -1) {
+				ecmd.advertising = advertising_wanted;
 			}
 
 			/* Try to perform the update. */
-- 
1.7.3.4


-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


^ permalink raw reply related

* Re: [net-2.6 0/4][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-02-17 20:44 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <1297935310-23510-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Feb 2011 01:35:06 -0800

> The following series contains two fixes for e1000e and ixgbe.
> 
> The following are changes since commit 6d90e8f45697c633f522269368297d7416fd8783:
>   isdn: hisax: Use l2headersize() instead of dup (and buggy) func.
> 
> and are available in the git repository at:
>   master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-2.6 master

Pulled, thanks Jeff.

^ permalink raw reply

* Re: [PATCH v2] bnx2x: Support for managing RX indirection table
From: David Miller @ 2011-02-17 20:49 UTC (permalink / raw)
  To: eilong; +Cc: eric.dumazet, therbert, netdev
In-Reply-To: <1297947524.4722.2.camel@lb-tlvb-eilong.il.broadcom.com>

From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Thu, 17 Feb 2011 14:58:44 +0200

> On Thu, 2011-02-17 at 01:09 -0800, Eric Dumazet wrote:
>> Le mercredi 16 février 2011 à 12:27 -0800, Tom Herbert a écrit :
>> > Support fetching and retrieving RX indirection table via ethtool.
>> > 
>> > Signed-off-by: Tom Herbert <therbert@google.com>
>> > ---
>> >  drivers/net/bnx2x/bnx2x.h         |    2 +
>> >  drivers/net/bnx2x/bnx2x_ethtool.c |   56 +++++++++++++++++++++++++++++++++++++
>> >  drivers/net/bnx2x/bnx2x_main.c    |   22 +++++++++++---
>> >  3 files changed, 75 insertions(+), 5 deletions(-)
>> 
>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> 
> Acked-by: Eilon Greenstein <eilong@broadcom.com>
> 
> Thanks everyone! 

Applied to net-next-2.6, thanks!

^ permalink raw reply

* Re: [PATCH 1/1] tproxy: do not assign timewait sockets to skb->sk
From: Florian Westphal @ 2011-02-17 20:52 UTC (permalink / raw)
  To: Balazs Scheidler
  Cc: Florian Westphal, netfilter-devel, netdev, KOVACS Krisztian
In-Reply-To: <1297972902.2253.51.camel@Nokia-N900-51-1>

Balazs Scheidler <bazsi@balabit.hu> wrote:
> the only issue I see with this solution is that late packets will not be delivered to the proper socket, and will possibly be going to the fwd chain, which might be unexpected.

Why?
They'll get the proper nfmark, so they will be routed to the local
machine. The tcp stack should find the tw socket via normal sk lookup.

Or am i missing something?

^ permalink raw reply

* Re: [PATCH 1/1] tproxy: do not assign timewait sockets to skb->sk
From: Florian Westphal @ 2011-02-17 21:27 UTC (permalink / raw)
  To: Balazs Scheidler
  Cc: Florian Westphal, netfilter-devel, netdev, KOVACS Krisztian
In-Reply-To: <1297976642.3789.5.camel@Nokia-N900-51-1>

Balazs Scheidler <bazsi@balabit.hu> wrote:
> the destination port in the packet can be different in the two lookups. --on-port tproxy option.

Hrm...  The initial lookup uses the header ip addresses:
        sk = nf_tproxy_get_sock_v4(dev_net(skb->dev), iph->protocol,
                                   iph->saddr, iph->daddr,
                                   hp->source, hp->dest,
                                   skb->dev, NFT_LOOKUP_ESTABLISHED);

3 possible cases:
- no socket -- try to find listener. This case is not changed by my patch.
- sk is normal socket. set nfmark and skb->sk. Also not changed.
- sk is in TW state. This is not changed either:
	tproxy_handle_time_wait4() will check if this is a SYN. If it is, a new
	listener lookup is made, and TW socket is kicked out.

If the packet is not a SYN, then tproxy_handle_time_wait4() won't do anything.
Previously, the timewait sk would now be assigned to skb->sk, which my patch
prevents.  But I don't see where the '--on-port' port number is involved in the
TW socket lookup?

Thanks for reviwing the patch!

^ permalink raw reply

* RE: ixgbe: 82599 and Westmere with HT
From: Skidmore, Donald C @ 2011-02-17 22:06 UTC (permalink / raw)
  To: Andrew Dickinson, netdev@vger.kernel.org
In-Reply-To: <AANLkTi=1d8aJoFU7gsNy-sYjJomGp-Xz4K+ddKSOk-ir@mail.gmail.com>


Hey Andrew,

Sorry about the slow reply I'm a bit backed up right now. :)

It sounds like you could be using using RSS hashing?  It's limited to 16 indices.  If you are using Flow Director hashing then maybe your flows aren't varying enough, although from your description it sounds as if they should be.  What if you try something like 'netperf -t TCP_CRR'.

Let me know if any of my assumptions are incorrect.

Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>


>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Andrew Dickinson
>Sent: Wednesday, February 16, 2011 5:22 PM
>To: netdev@vger.kernel.org
>Subject: ixgbe: 82599 and Westmere with HT
>
>Hi,
>
>I've got a dual Westmere board (X5675) with an X520 card with dual
>10G.  I see 24-cores exposed to me and the ixgbe driver exposes 24 tx
>and 24 rx interrupts per NIC.  I then pin the interrupts to cores for
>each NIC (each interrupt gets its own core, standard stuff).
>
>Anyway.... I'm only seeing RX interrupts on 16 of the 24 cores (random
>src/dest pairs across a /16 each, so I should be getting good flow
>hashing).  Did I miss some magic somewhere?
>
>I'm running 2.6.32.4, perhaps this has been fixed upstream.  If not,
>any thoughts on how to make this work?
>
>-A
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] drivers/net: Call netif_carrier_off at the end of the probe
From: David Miller @ 2011-02-17 22:10 UTC (permalink / raw)
  To: ivecera; +Cc: netdev, romieu, aabdulla
In-Reply-To: <1297771719-14202-1-git-send-email-ivecera@redhat.com>

From: Ivan Vecera <ivecera@redhat.com>
Date: Tue, 15 Feb 2011 13:08:39 +0100

> Without calling of netif_carrier_off at the end of the probe the operstate
> is unknown when the device is initially opened. By default the carrier is
> on so when the device is opened and netif_carrier_on is called the link
> watch event is not fired and operstate remains zero (unknown).
> 
> This patch fixes this behavior in forcedeth and r8169.
> 
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>

Applied, thanks Ivan.

^ permalink raw reply

* Re: [PATCH net-2.6/stable] tg3: Restrict phy ioctl access
From: David Miller @ 2011-02-17 22:11 UTC (permalink / raw)
  To: mcarlson; +Cc: netdev, stable
In-Reply-To: <1297810270-4690-1-git-send-email-mcarlson@broadcom.com>

From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Tue, 15 Feb 2011 14:51:10 -0800

> If management firmware is present and the device is down, the firmware
> will assume control of the phy.  If a phy access were allowed from the
> host, it will collide with firmware phy accesses, resulting in
> unpredictable behavior.  This patch fixes the problem by disallowing phy
> accesses during the problematic condition.
> 
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Reviewed-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>

Applied.

^ permalink raw reply

* Re: [net-next-2.6 PATCH 3/3] enic: Always use single transmit and single receive hardware queues per device
From: David Miller @ 2011-02-17 22:12 UTC (permalink / raw)
  To: vkolluri; +Cc: netdev
In-Reply-To: <20110217185322.2476.10728.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Thu, 17 Feb 2011 10:53:22 -0800

> From: Vasanthy Kolluri <vkolluri@cisco.com>
> 
> 
> 
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Danny Guo <dannguo@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>

You can't make a very serious change like this with such a terse commit
message, you have to explain exactly why this change is being made.

^ permalink raw reply

* Re: [net-next-2.6 PATCH 1/3] enic: Bug fix: Reset driver count of registered unicast addresses to zero during device reset
From: David Miller @ 2011-02-17 22:14 UTC (permalink / raw)
  To: vkolluri; +Cc: netdev
In-Reply-To: <20110217185311.2476.27883.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Thu, 17 Feb 2011 10:53:12 -0800

> From: Vasanthy Kolluri <vkolluri@cisco.com>
> 
> During a device reset, clear the counter for the no. of unicast addresses registered.
> Also, rename the routines that update unicast and multicast address lists.
> 
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Danny Guo <dannguo@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>

Applied.

^ permalink raw reply

* Re: [net-next-2.6 PATCH 2/3] enic: Clean up: Remove a not needed #ifdef
From: David Miller @ 2011-02-17 22:14 UTC (permalink / raw)
  To: vkolluri; +Cc: netdev
In-Reply-To: <20110217185317.2476.75828.stgit@savbu-pc100.cisco.com>

From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Thu, 17 Feb 2011 10:53:17 -0800

> From: Vasanthy Kolluri <vkolluri@cisco.com>
> 
> 
> 
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Danny Guo <dannguo@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>

Applied.

^ permalink raw reply

* Re: [Bugme-new] [Bug 29252] New: IPv6 doesn't work in a kvm guest.
From: Andrew Morton @ 2011-02-17 22:25 UTC (permalink / raw)
  To: netdev; +Cc: bugzilla-daemon, bugme-daemon, David Miller, slash
In-Reply-To: <bug-29252-10286@https.bugzilla.kernel.org/>


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 16 Feb 2011 13:03:15 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=29252
> 
>            Summary: IPv6 doesn't work in a kvm guest.
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 2.6.38-rc5
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV6
>         AssignedTo: yoshfuji@linux-ipv6.org
>         ReportedBy: slash@ac.auone-net.jp
>         Regression: Yes
> 
> 
> apt-get and ping6 don't work in a kvm guest. It appears that neighbor discovery
> is not working. I'm using tap, virtio-net and vhost. I did bisect and results
> is
> 
> d80bc0fd262ef840ed4e82593ad6416fa1ba3fc4 is the first bad commit
> commit d80bc0fd262ef840ed4e82593ad6416fa1ba3fc4
> Author: David S. Miller <davem@davemloft.net>
> Date:   Mon Jan 24 16:01:58 2011 -0800
> 
>     ipv6: Always clone offlink routes.
> 
>     Do not handle PMTU vs. route lookup creation any differently
>     wrt. offlink routes, always clone them.
> 
>     Reported-by: PK <runningdoglackey@yahoo.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> :040000 040000
> c4a34e9e36bd8cc81e898738f2d4344f6647d472f0fcd4b093ec22784798f3951203391f4567b278
> M      net
> 
> reverting this commit for guest kernel fixes the probrem.
> 


^ permalink raw reply

* Re: [Bugme-new] [Bug 29252] New: IPv6 doesn't work in a kvm guest.
From: David Miller @ 2011-02-17 22:32 UTC (permalink / raw)
  To: akpm; +Cc: netdev, bugzilla-daemon, bugme-daemon, slash
In-Reply-To: <20110217142517.b9919481.akpm@linux-foundation.org>

From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 17 Feb 2011 14:25:17 -0800

>> https://bugzilla.kernel.org/show_bug.cgi?id=29252
 ...
>> apt-get and ping6 don't work in a kvm guest. It appears that neighbor discovery
>> is not working. I'm using tap, virtio-net and vhost. I did bisect and results
>> is
>> 
>> d80bc0fd262ef840ed4e82593ad6416fa1ba3fc4 is the first bad commit
>> commit d80bc0fd262ef840ed4e82593ad6416fa1ba3fc4
>> Author: David S. Miller <davem@davemloft.net>
>> Date:   Mon Jan 24 16:01:58 2011 -0800
>> 
>>     ipv6: Always clone offlink routes.
>> 
>>     Do not handle PMTU vs. route lookup creation any differently
>>     wrt. offlink routes, always clone them.
>> 
>>     Reported-by: PK <runningdoglackey@yahoo.com>
>>     Signed-off-by: David S. Miller <davem@davemloft.net>
>> 
>> :040000 040000
>> c4a34e9e36bd8cc81e898738f2d4344f6647d472f0fcd4b093ec22784798f3951203391f4567b278
>> M      net
>> 
>> reverting this commit for guest kernel fixes the probrem.

Thanks for the report, I'll look into this.

^ permalink raw reply

* [PATCH 15/14] net/fec: remove unused driver data
From: Uwe Kleine-König @ 2011-02-17 22:32 UTC (permalink / raw)
  To: netdev; +Cc: Marc Kleine-Budde, kernel
In-Reply-To: <1297420342-17739-1-git-send-email-u.kleine-koenig@pengutronix.de>

Apart from not being used the first argument isn't even a struct
platform_device *.

Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,

this patch is available at

	git://git.pengutronix.de/git/ukl/linux-2.6.git fec

based on the patches already merged into net-next.

Use whatever is easier for you.

Best regards
Uwe

 drivers/net/fec.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 74798be..634c0da 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -983,8 +983,6 @@ static int fec_enet_mii_init(struct platform_device *pdev)
 	for (i = 0; i < PHY_MAX_ADDR; i++)
 		fep->mii_bus->irq[i] = PHY_POLL;
 
-	platform_set_drvdata(ndev, fep->mii_bus);
-
 	if (mdiobus_register(fep->mii_bus))
 		goto err_out_free_mdio_irq;
 
-- 
1.7.2.3


^ permalink raw reply related

* RE: [net-next-2.6 PATCH 3/3] enic: Always use single transmit and single receive hardware queues per device
From: Vasanthy Kolluri (vkolluri) @ 2011-02-17 22:45 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20110217.141235.48514315.davem@davemloft.net>

Hi Dave,

Sorry for the short description.

We believe that our earlier patch for supporting multiple hardware
receive queues per enic device requires more internal testing. At this
point, we think that it's best to disable the use of multiple receive
queues. We believe that the current patch will provide an effective
means for the same.

Thanks
Vasanthy

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net] 
Sent: Thursday, February 17, 2011 2:13 PM
To: Vasanthy Kolluri (vkolluri)
Cc: netdev@vger.kernel.org
Subject: Re: [net-next-2.6 PATCH 3/3] enic: Always use single transmit
and single receive hardware queues per device

From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Thu, 17 Feb 2011 10:53:22 -0800

> From: Vasanthy Kolluri <vkolluri@cisco.com>
> 
> 
> 
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Danny Guo <dannguo@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>

You can't make a very serious change like this with such a terse commit
message, you have to explain exactly why this change is being made.

^ permalink raw reply

* Re: [net-next-2.6 PATCH 3/3] enic: Always use single transmit and single receive hardware queues per device
From: David Miller @ 2011-02-17 22:48 UTC (permalink / raw)
  To: vkolluri; +Cc: netdev
In-Reply-To: <212AA327A3557741A058E787E06188730564B99A@xmb-sjc-219.amer.cisco.com>

From: "Vasanthy Kolluri (vkolluri)" <vkolluri@cisco.com>
Date: Thu, 17 Feb 2011 14:45:56 -0800

> Sorry for the short description.
> 
> We believe that our earlier patch for supporting multiple hardware
> receive queues per enic device requires more internal testing. At this
> point, we think that it's best to disable the use of multiple receive
> queues. We believe that the current patch will provide an effective
> means for the same.

Well then, resubmit your patch with an appropriate commit message.

^ permalink raw reply

* Re: IGMP and rwlock: Dead ocurred again on TILEPro
From: Chris Metcalf @ 2011-02-17 22:49 UTC (permalink / raw)
  To: David Miller; +Cc: xiyou.wangcong, cypher.w, linux-kernel, eric.dumazet, netdev
In-Reply-To: <20110216.214625.189707123.davem@davemloft.net>

On 2/17/2011 12:46 AM, David Miller wrote:
> From: Américo Wang <xiyou.wangcong@gmail.com>
> Date: Thu, 17 Feb 2011 13:42:37 +0800
>
>> On Thu, Feb 17, 2011 at 01:04:14PM +0800, Cypher Wu wrote:
>>>> Have you turned CONFIG_LOCKDEP on?
>>>>
>>>> I think Eric already converted that rwlock into RCU lock, thus
>>>> this problem should disappear. Could you try a new kernel?
>>>>
>>>> Thanks.
>>>>
>>> I haven't turned CONFIG_LOCKDEP on for test since I didn't get too
>>> much information when we tried to figured out the former deadlock.
>>>
>>> IGMP used read_lock() instead of read_lock_bh() since usually
>>> read_lock() can be called recursively, and today I've read the
>>> implementation of MIPS, it's should also works fine in that situation.
>>> The implementation of TILEPro cause problem since after it use TNS set
>>> the lock-val to 1 and hold the original value and before it re-set
>>> lock-val a new value, it a race condition window.
>>>
>> I see no reason why you can't call read_lock_bh() recursively,
>> read_lock_bh() is roughly equalent to local_bh_disable() + read_lock(),
>> both can be recursive.
>>
>> But I may miss something here. :-/
> IGMP is doing this so that taking the read lock does not stop packet
> processing.
>
> TILEPro's rwlock implementation is simply buggy and needs to be fixed.

Cypher, thanks for tracking this down with a good bug report.

The fix is to disable interrupts for the arch_read_lock family of methods. 
In my fix I'm using the "hard" disable that locks out NMIs as well, so that
in the event the NMI handler needs to share an rwlock with regular code it
would be possible (plus, it's more efficient).  I believe it's not
necessary to worry about similar protection for the arch_write_lock
methods, since they aren't guaranteed to be re-entrant anyway (you'd have
to use write_lock_irqsave or equivalent).

I'll send the patch to LKML after letting it bake internally for a little
while.

Thanks again!

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

^ permalink raw reply

* Re: IGMP and rwlock: Dead ocurred again on TILEPro
From: David Miller @ 2011-02-17 22:53 UTC (permalink / raw)
  To: cmetcalf; +Cc: xiyou.wangcong, cypher.w, linux-kernel, eric.dumazet, netdev
In-Reply-To: <4D5DA60A.8080201@tilera.com>

From: Chris Metcalf <cmetcalf@tilera.com>
Date: Thu, 17 Feb 2011 17:49:46 -0500

> The fix is to disable interrupts for the arch_read_lock family of methods. 

How does that help handle the race when it happens between different
cpus, instead of between IRQ and non-IRQ context on the same CPU?

Why don't you just use the generic spinlock based rwlock code on Tile,
since that is all that your atomic instructions can handle
sufficiently?

^ 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