* [PATCH 3/3] net: deliver skbs on inactive slaves to exact matches
From: John Fastabend @ 2010-05-13 7:31 UTC (permalink / raw)
To: andy, fubar, nhorman, bonding-devel, netdev; +Cc: john.r.fastabend
In-Reply-To: <20100513073106.3528.45412.stgit@jf-dev2-dcblab>
Currently, the accelerated receive path for VLAN's will
drop packets if the real device is an inactive slave and
is not one of the special pkts tested for in
skb_bond_should_drop(). This behavior is different then
the non-accelerated path and for pkts over a bonded vlan.
For example,
vlanx -> bond0 -> ethx
will be dropped in the vlan path and not delivered to any
packet handlers at all. However,
bond0 -> vlanx -> ethx
and
bond0 -> ethx
will be delivered to handlers that match the exact dev,
because the VLAN path checks the real_dev which is not a
slave and netif_recv_skb() doesn't drop frames but only
delivers them to exact matches.
This patch adds a sk_buff flag which is used for tagging
skbs that would previously been dropped and allows the
skb to continue to skb_netif_recv(). Here we add
logic to check for the bond_should_drop flag and if it
is set only deliver to handlers that match exactly. This
makes both paths above consistent and gives pkt handlers
a way to identify skbs that come from inactive slaves.
Without this patch in some configurations skbs will be
delivered to handlers with exact matches and in others
be dropped out right in the vlan path.
I have tested the following 4 configurations in failover modes
and load balancing modes.
# bond0 -> ethx
# vlanx -> bond0 -> ethx
# bond0 -> vlanx -> ethx
# bond0 -> ethx
|
vlanx -> --
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
include/linux/skbuff.h | 8 +++++++-
net/8021q/vlan_core.c | 8 ++++++--
net/core/dev.c | 23 +++++++++++++++++++----
3 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c9525bc..5ba4fd5 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -379,8 +379,14 @@ struct sk_buff {
kmemcheck_bitfield_begin(flags2);
__u16 queue_mapping:16;
-#ifdef CONFIG_IPV6_NDISC_NODETYPE
+#if defined(CONFIG_IPV6_NDISC_NODETYPE) && \
+ (defined(CONFIG_BONDING) || defined(CONFIG_BONDING_MODULE))
+ __u8 ndisc_nodetype:2,
+ bond_should_drop:1;
+#elif defined(CONFIG_IPV6_NDISC_NODETYPE)
__u8 ndisc_nodetype:2;
+#elif defined(CONFIG_BONDING) || defined(CONFIG_BONDING_MODULE)
+ __u8 bond_should_drop:1;
#endif
kmemcheck_bitfield_end(flags2);
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index c584a0a..57ac2d3 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -11,8 +11,10 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
if (netpoll_rx(skb))
return NET_RX_DROP;
+#if defined(CONFIG_BONDING) || defined(CONFIG_BONDING_MODULE)
if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
- goto drop;
+ skb->bond_should_drop = 1;
+#endif
skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
@@ -83,8 +85,10 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
{
struct sk_buff *p;
+#if defined(CONFIG_BONDING) || defined(CONFIG_BONDING_MODULE)
if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master)))
- goto drop;
+ skb->bond_should_drop = 1;
+#endif
skb->skb_iif = skb->dev->ifindex;
__vlan_hwaccel_put_tag(skb, vlan_tci);
diff --git a/net/core/dev.c b/net/core/dev.c
index 3dc691d..92fdff4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2782,11 +2782,13 @@ static int __netif_receive_skb(struct sk_buff *skb)
{
struct packet_type *ptype, *pt_prev;
struct net_device *orig_dev;
- struct net_device *master;
struct net_device *null_or_orig;
struct net_device *orig_or_bond;
int ret = NET_RX_DROP;
__be16 type;
+#if defined(CONFIG_BONDING) || defined(CONFIG_BONDING_MODULE)
+ struct net_device *master;
+#endif
if (!skb->tstamp.tv64)
net_timestamp(skb);
@@ -2801,15 +2803,28 @@ static int __netif_receive_skb(struct sk_buff *skb)
if (!skb->skb_iif)
skb->skb_iif = skb->dev->ifindex;
+ /*
+ * bonding note: skbs received on inactive slaves should only
+ * be delivered to pkt handlers that are exact matches. Also
+ * the bond_should_drop flag will be set. If packet handlers
+ * are sensitive to duplicate packets these skbs will need to
+ * be dropped at the handler. The vlan accel path may have
+ * already set the bond_should_drop flag.
+ */
null_or_orig = NULL;
orig_dev = skb->dev;
+#if defined(CONFIG_BONDING) || defined(CONFIG_BONDING_MODULE)
master = ACCESS_ONCE(orig_dev->master);
- if (master) {
- if (skb_bond_should_drop(skb, master))
+ if (skb->bond_should_drop)
+ null_or_orig = orig_dev;
+ else if (master) {
+ if (skb_bond_should_drop(skb, master)) {
+ skb->bond_should_drop = 1;
null_or_orig = orig_dev; /* deliver only exact match */
- else
+ } else
skb->dev = master;
}
+#endif
__get_cpu_var(softnet_data).processed++;
^ permalink raw reply related
* [PATCH 2/3] net: fix conflict between null_or_orig and null_or_bond
From: John Fastabend @ 2010-05-13 7:31 UTC (permalink / raw)
To: andy, fubar, nhorman, bonding-devel, netdev; +Cc: john.r.fastabend
In-Reply-To: <20100513073106.3528.45412.stgit@jf-dev2-dcblab>
If a skb is received on an inactive bond that does not meet
the special cases checked for by skb_bond_should_drop it should
only be delivered to exact matches as the comment in
netif_receive_skb() says.
However because null_or_bond could also be null this is not
always true. This patch renames null_or_bond to orig_or_bond
and initializes it to orig_dev. This keeps the intent of
null_or_bond to pass frames received on VLAN interfaces stacked
on bonding interfaces without invalidating the statement for
null_or_orig.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/core/dev.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 32611c8..3dc691d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2784,7 +2784,7 @@ static int __netif_receive_skb(struct sk_buff *skb)
struct net_device *orig_dev;
struct net_device *master;
struct net_device *null_or_orig;
- struct net_device *null_or_bond;
+ struct net_device *orig_or_bond;
int ret = NET_RX_DROP;
__be16 type;
@@ -2857,10 +2857,10 @@ ncls:
* device that may have registered for a specific ptype. The
* handler may have to adjust skb->dev and orig_dev.
*/
- null_or_bond = NULL;
+ orig_or_bond = orig_dev;
if ((skb->dev->priv_flags & IFF_802_1Q_VLAN) &&
(vlan_dev_real_dev(skb->dev)->priv_flags & IFF_BONDING)) {
- null_or_bond = vlan_dev_real_dev(skb->dev);
+ orig_or_bond = vlan_dev_real_dev(skb->dev);
}
type = skb->protocol;
@@ -2868,7 +2868,7 @@ ncls:
&ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
if (ptype->type == type && (ptype->dev == null_or_orig ||
ptype->dev == skb->dev || ptype->dev == orig_dev ||
- ptype->dev == null_or_bond)) {
+ ptype->dev == orig_or_bond)) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = ptype;
^ permalink raw reply related
* [PATCH 1/3] net: init_vlan should not copy slave or master flags
From: John Fastabend @ 2010-05-13 7:31 UTC (permalink / raw)
To: andy, fubar, nhorman, bonding-devel, netdev; +Cc: john.r.fastabend
The vlan device should not copy the slave or master flags from
the real device. It is not in the bond until added nor is it
a master.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/8021q/vlan_dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index b5249c5..c13d8a3 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -708,7 +708,8 @@ static int vlan_dev_init(struct net_device *dev)
netif_carrier_off(dev);
/* IFF_BROADCAST|IFF_MULTICAST; ??? */
- dev->flags = real_dev->flags & ~(IFF_UP | IFF_PROMISC | IFF_ALLMULTI);
+ dev->flags = real_dev->flags & ~(IFF_UP | IFF_PROMISC | IFF_ALLMULTI |
+ IFF_MASTER | IFF_SLAVE);
dev->iflink = real_dev->ifindex;
dev->state = (real_dev->state & ((1<<__LINK_STATE_NOCARRIER) |
(1<<__LINK_STATE_DORMANT))) |
^ permalink raw reply related
* Re: [PATCH] skge: use the DMA state API instead of the pci equivalents
From: David Miller @ 2010-05-13 6:43 UTC (permalink / raw)
To: fujita.tomonori; +Cc: netdev, shemminger
In-Reply-To: <20100428095730K.fujita.tomonori@lab.ntt.co.jp>
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Wed, 28 Apr 2010 09:57:04 +0900
> This replace the PCI DMA state API (include/linux/pci-dma.h) with the
> DMA equivalents since the PCI DMA state API will be obsolete.
>
> No functional change.
>
> For further information about the background:
>
> http://marc.info/?l=linux-netdev&m=127037540020276&w=2
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Stephen, ping? How did the testing go?
^ permalink raw reply
* Re: [PATCH] rndis_host: Poll status channel before control channel
From: David Miller @ 2010-05-13 6:42 UTC (permalink / raw)
To: ben; +Cc: dbrownell, john.carr, netdev, vzeeaxwl, herton
In-Reply-To: <1271718508.2197.12.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Tue, 20 Apr 2010 00:08:28 +0100
> Some RNDIS devices don't respond on the control channel until polled
> on the status channel. In particular, this was reported to be the
> case for the 2Wire HomePortal 1000SW.
>
> This is roughly based on a patch by John Carr <john.carr@unrouted.co.uk>
> which is reported to be needed for use with some Windows Mobile devices
> and which is currently applied by Mandriva.
>
> Reported-by: Mark Glassberg <vzeeaxwl@myfairpoint.net>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> Tested-by: Mark Glassberg <vzeeaxwl@myfairpoint.net>
> ---
> Note that this change hasn't yet been tested with any other RNDIS
> devices. John, can you confirm whether this also handles the WinMob
> devices?
Still waiting for this to get tested. Is there really nobody in the
world with RNDIS devices who can test this patch? If so, maybe that's
a good reason to not apply it :-))))
^ permalink raw reply
* Re: [PATCH v3 0/4] xfrm: add x86 CONFIG_COMPAT support
From: David Miller @ 2010-05-13 6:41 UTC (permalink / raw)
To: fw; +Cc: netdev, johannes
In-Reply-To: <1270506431-25578-1-git-send-email-fw@strlen.de>
I'm officially deferring this patch set for now, sorry.
I can't see applying this if it will fix only some subset of
known applications. We need buy-in on the read/write vfs ops
override so we can do this properly.
Thanks for all of your efforts Florian.
^ permalink raw reply
* Re: [PATCH net-next 3/3] cxgb4: report GRO stats with ethtool -S
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: dm; +Cc: netdev
In-Reply-To: <1273543089-10938-3-git-send-email-dm@chelsio.com>
From: Dimitris Michailidis <dm@chelsio.com>
Date: Mon, 10 May 2010 18:58:09 -0700
> Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] cxgb4: report the PCIe link speed
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: dm; +Cc: netdev
In-Reply-To: <1273543089-10938-2-git-send-email-dm@chelsio.com>
From: Dimitris Michailidis <dm@chelsio.com>
Date: Mon, 10 May 2010 18:58:08 -0700
> Report the PCIe link speed (2.5 or 5 Gbps).
>
> Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/3] cxgb4: configure HW VLAN extraction through FW
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: dm; +Cc: netdev
In-Reply-To: <1273543089-10938-1-git-send-email-dm@chelsio.com>
From: Dimitris Michailidis <dm@chelsio.com>
Date: Mon, 10 May 2010 18:58:07 -0700
> HW VLAN extraction needs to be configured through FW to work correctly in
> virtualization environments. Remove the direct register manipulation and
> rely on FW.
>
> Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 12/12] e1000e: add PCI device id to enable support for 82567V-4
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010250.30827.86831.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:02:52 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 11/12] e1000e: Fix/cleanup PHY reset code for ICHx/PCHx
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010230.30827.69868.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:02:32 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> i) Fixes a bug where e1000_sw_lcd_config_ich8lan() was calling
> e1000_lan_init_done_ich8lan() to poll the STATUS.LAN_INIT_DONE bit to
> make sure the MAC had completed the PHY configuration. However,
> e1000_lan_init_done_ich8lan() had already been called in one of the two
> places where PHY reset occurs for ICHx/PCHx parts, which caused the second
> call to busy-wait for 150 msec because the LAN_INIT_DONE bit had already
> been checked and cleared.
>
> ii) Cleanup the two separate PHY reset code paths, i.e. the full-chip reset
> in e1000_reset_hw_ich8lan() and the PHY-only reset in
> e1000_phy_hw_reset_ich8lan(). There was duplicate code in both paths to be
> performed post-reset that are now combined into one new function -
> e1000_post_phy_reset_ich8lan(). This cleanup also included moving the
> clearing of the PHY Reset Asserted bit in the STATUS register (now done for
> all ICH/PCH parts) and the check for the indication from h/w that basic
> configuration has completed back to where it previously was in
> e1000_get_cfg_done_ich8lan().
>
> iii) Corrected a few comments
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 10/12] e1000e: move settting of flow control refresh timer to link setup code
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010210.30827.6899.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:02:12 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The flow control refresh timer value needs to be saved off so that it can
> be programmed into the approrpiate register when applicable but without a
> reset, e.g. when changing flow control parameters via ethtool.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 09/12] e1000e: fix checks for manageability enabled and management pass-through
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010150.30827.4384.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:01:51 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The mac->arc_subsystem was being incorrectly used to flag whether or not
> manageability was enabled when it should only be used to state whether the
> ARC (Host interface) subsystem is available on a particular MAC _and_ only
> valid when any manageability is enabled. The ARC subsystem is currently
> only available on 80003es2lan and 82573 parts supported by the driver.
>
> A new flag, has_fwsm, is introduced to be used when checking if
> manageability is enabled but only on parts that acutally have an FWSM
> register. While the above parts have an FWSM register, there are other
> parts that have FWSM but do not have support for the ARC subsystem,
> namely 82571/2 and ICHx/PCH.
>
> And then there are parts that have manageability, but do not have either
> FWSM register or support for the ARC subsystem - these are 82574 and 82583.
>
> For 80003es2lan, 82571/2/3 and ICH/PCH parts, this patch makes no
> functional changes, it only corrects the usage of the manageability flags.
> For 82574 and 82583, it fixes the incorrect accesses of the non-existent
> FWSM register and ARC subsystem as well as corrects the check for
> management pass-through.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 08/12] e1000e: Incorrect function pointer set for force_speed_duplex on 82577
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010128.30827.12447.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:01:30 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The force_speed_duplex function pointer was incorrectly set. Instead of
> calling the 82577-specific version it was calling the m88 version which,
> among other incorrect things, reset the PHY causing autonegotiation to be
> re-enabled in the PHY resulting in the link defaulting to half-duplex.
> The 82577-specific force_speed_duplex function also had an issue where
> it disabled Auto-MDI-X which caused the link to not come up.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 07/12] e1000e: Cleanup e1000_sw_lcd_config_ich8lan()
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010108.30827.47964.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:01:10 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> After every reset all ICH/PCH parts call this function which acquires the
> swflag, performs a workaround on applicable parts and releases the swflag.
> There is no reason for parts for which this workaround is not applicable
> to acquire and release the swflag so the function should just return
> without doing anything for these parts. This also provides for the
> indentation of most of the function contents to be shifted left cleaning up
> the code.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 06/12] e1000e: Remove EN_MAC_ADDR_FILTER check from enable_mng_pass_thru check
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010048.30827.12737.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:00:50 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Patch addresses issues when manageability passthrough is enabled, but the
> MAC_ADDR_FILTER bit is not set in the MANC register.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 05/12] e1000e: cleanup multiple common exit points
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010029.30827.82837.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:00:31 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> ...in e1000_update_nvm_checksum_ich8lan().
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 04/12] e1000e: s/w initiated LSC MSI-X interrupts not generated; no transmit
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010008.30827.45897.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:00:10 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> In MSI-X mode when an IMPI SoL session was active (i.e. the PHY reset was
> blocked), the LSC interrupt generated by s/w to start the watchdog which
> started the transmitter was not getting fired by the hardware because bit
> 24 (the 'other' cause bit) also needed to be set. Without an active SoL
> session, the PHY was reset which caused the h/w to fire the LSC interrupt.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 03/12] e1000e: initialize manageability (IPMI) pass-through in 82574/82583
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511005949.30827.62576.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 17:59:51 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> 82574/82583 uses different registers/bits to setup manageability filters
> than all other parts supported by e1000e; set them accordingly for IPMI
> pass-through. Rename the function to better reflect what it does.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 02/12] e1000e: bad state after running ethtool diagnostics with AMT enabled
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511005929.30827.30176.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 17:59:31 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> When running ethtool online diagnostics with no open interface, there is a
> short period of time where the driver relinquishes control of the adapter
> during which time AMT (manageability firmware) can put the adapter into an
> unknown state resulting in such things as link test failure, hardware hang,
> reporting an incorrect link speed, etc. Resetting the adapter during an
> open() resolves this by putting the adapter into a quiescent state.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 01/12] e1000e: use static params to save stack space (part 2)
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan, jesse.brandeburg
In-Reply-To: <20100511005801.30827.50808.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 17:59:10 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> A couple stack cleanups missed in an earlier patch from Jesse.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/6] ipv6: ip6mr: support multiple independant multicast routing instances
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <1273586551-3521-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Tue, 11 May 2010 16:02:25 +0200
> The following patches add support for multiple independant IPv6 multicast
> routing instances. This can be useful to seperate traffic when building
> a multicast router that is serving multiple independant networks.
>
> The patchset is pretty much a straight forward port from IPv4 with no
> significant differences.
...
> These patches have been tested using pim6sd and mrd6.
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/ipmr-2.6.git master
Pulled, thanks!
^ permalink raw reply
* Re: [PATCH NEXT 0/4]netxen: bug fixes
From: David Miller @ 2010-05-13 6:29 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1273657985-13405-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Wed, 12 May 2010 02:53:01 -0700
> Series of 4 patches to fix diagnostic tools access and register usage
> for NX3031.
> Please apply them on net-next branch.
All applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/16] tipc: 1st integration of basic changes from sourceforge
From: David Miller @ 2010-05-13 6:28 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, allan.stephens
In-Reply-To: <1273624218-22514-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Tue, 11 May 2010 20:30:02 -0400
> The following patches are step one in making use of the changes that
> were stored away on sourceforge but not yet integrated into the kernel.
>
> Since I am far from knowledgeable on tipc, this starts by pulling in
> the 1st batch of basic/cosmetic changes that will at least start to
> reduce the delta between the two. Hopefully getting all the simple
> stuff out of the way 1st will help clarify what is left of interest.
>
> I've also put the same commits on the branch tipc-May11_2010 in:
> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6.git
> in case that is more convenient for people.
All applied to net-next-2.6, thanks for doing this work Paul.
^ permalink raw reply
* RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
From: Ha, Tristram @ 2010-05-13 5:38 UTC (permalink / raw)
To: Arce, Abraham, Ben Dooks
Cc: David Miller, netdev, linux-kernel, Jan, Sebastien
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A53043DF7779A@dlee03.ent.ti.com>
I use a web browser to send patches through my company's e-mail system. The message is composed by cut and paste, so it may not conform to Linux standard.
The latest nuttcp default size for UDP is 1500 bytes, rather than 8192 bytes. In my case, the transmit performance improves from 10 Mbps to 11. Have you tried TCP?
-----Original Message-----
From: Arce, Abraham [mailto:x0066660@ti.com]
Sent: Thu 5/6/2010 10:02 PM
To: Ha, Tristram; Ben Dooks
Cc: David Miller; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Jan, Sebastien
Subject: RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
Hi,
[snip]
> There is a driver option no_tx_opt so that the driver can revert to original
> implementation. This allows user to verify if the transmit performance
> actually improves.
Should we limit patch description to 80 characters also?
> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
> ---
> This replaces the [patch 01/13] patch I submitted and was objected by David.
>
> Other users with Micrel KSZ8851 SNL chip please verify the transmit
> performance does improve or not.
Tested-by: Abraham Arce <x0066660@ti.com>
Executing some nuttcp scenarios:
- Without Patch -
# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m <serverip>
1.2676 MB / 1.00 sec = 10.6330 Mbps 0 / 1298 ~drop/pkt 0.00 ~%loss
1.2705 MB / 1.00 sec = 10.6579 Mbps 0 / 1301 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6496 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6496 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2646 MB / 1.00 sec = 10.6086 Mbps 0 / 1295 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6412 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6498 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
12.7314 MB / 10.02 sec = 10.6637 Mbps 4 %TX 0 %RX 0 / 13037 drop/pkt 0.00 %loss
- With Patch -
# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m 10.87.231.229
1.2891 MB / 1.00 sec = 10.8133 Mbps 0 / 1320 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8217 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8217 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8298 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8299 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2891 MB / 1.00 sec = 10.8135 Mbps 0 / 1320 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8298 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
12.9492 MB / 10.02 sec = 10.8461 Mbps 4 %TX 0 %RX 0 / 13260 drop/pkt 0.00
%loss
Also simulated heavy transmission consisting of 40 processes executed in parallel:
- 20 ping instances using packet size of 32768
- 20 dd instances creating a 50MB file each under the nfs rootfs
If any specific test scenario/application is required please do let me know...
Best Regards
Abraham
^ 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