* Re: Irq architecture for multi-core network driver.
From: Chris Friesen @ 2009-10-22 22:05 UTC (permalink / raw)
To: David Daney; +Cc: netdev, Linux Kernel Mailing List, linux-mips
In-Reply-To: <4AE0D14B.1070307@caviumnetworks.com>
On 10/22/2009 03:40 PM, David Daney wrote:
> The main problem I have encountered is how to fit the interrupt
> management into the kernel framework. Currently the interrupt source
> is connected to a single irq number. I request_irq, and then manage
> the masking and unmasking on a per cpu basis by directly manipulating
> the interrupt controller's affinity/routing registers. This goes
> behind the back of all the kernel's standard interrupt management
> routines. I am looking for a better approach.
>
> One thing that comes to mind is that I could assign a different
> interrupt number per cpu to the interrupt signal. So instead of
> having one irq I would have 32 of them. The driver would then do
> request_irq for all 32 irqs, and could call enable_irq and disable_irq
> to enable and disable them. The problem with this is that there isn't
> really a single packets-ready signal, but instead 16 of them. So If I
> go this route I would have 16(lines) x 32(cpus) = 512 interrupt
> numbers just for the networking hardware, which seems a bit excessive.
Does your hardware do flow-based queues? In this model you have
multiple rx queues and the hardware hashes incoming packets to a single
queue based on the addresses, ports, etc. This ensures that all the
packets of a single connection always get processed in the order they
arrived at the net device.
Typically in this model you have as many interrupts as queues
(presumably 16 in your case). Each queue is assigned an interrupt and
that interrupt is affined to a single core.
The intel igb driver is an example of one that uses this sort of design.
Chris
^ permalink raw reply
* Re: Irq architecture for multi-core network driver.
From: David Daney @ 2009-10-22 22:24 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev, Linux Kernel Mailing List, linux-mips
In-Reply-To: <4AE0D72A.4090607@nortel.com>
Chris Friesen wrote:
> On 10/22/2009 03:40 PM, David Daney wrote:
>
>> The main problem I have encountered is how to fit the interrupt
>> management into the kernel framework. Currently the interrupt source
>> is connected to a single irq number. I request_irq, and then manage
>> the masking and unmasking on a per cpu basis by directly manipulating
>> the interrupt controller's affinity/routing registers. This goes
>> behind the back of all the kernel's standard interrupt management
>> routines. I am looking for a better approach.
>>
>> One thing that comes to mind is that I could assign a different
>> interrupt number per cpu to the interrupt signal. So instead of
>> having one irq I would have 32 of them. The driver would then do
>> request_irq for all 32 irqs, and could call enable_irq and disable_irq
>> to enable and disable them. The problem with this is that there isn't
>> really a single packets-ready signal, but instead 16 of them. So If I
>> go this route I would have 16(lines) x 32(cpus) = 512 interrupt
>> numbers just for the networking hardware, which seems a bit excessive.
>
> Does your hardware do flow-based queues? In this model you have
> multiple rx queues and the hardware hashes incoming packets to a single
> queue based on the addresses, ports, etc. This ensures that all the
> packets of a single connection always get processed in the order they
> arrived at the net device.
>
Indeed, this is exactly what we have.
> Typically in this model you have as many interrupts as queues
> (presumably 16 in your case). Each queue is assigned an interrupt and
> that interrupt is affined to a single core.
Certainly this is one mode of operation that should be supported, but I
would also like to be able to go for raw throughput and have as many
cores as possible reading from a single queue (like I currently have).
>
> The intel igb driver is an example of one that uses this sort of design.
>
Thanks, I will look at that driver.
David Daney
^ permalink raw reply
* [PATCH net-2.6] sfc: 10Xpress: Report support for pause frames
From: Ben Hutchings @ 2009-10-22 22:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
Commits 27fbc7d 'mdio: Expose pause frame advertising flags to ethtool'
and c634263 'sfc: 10Xpress: Initialise pause advertising flags'
added to our reported advertising flags.
efx_mdio_set_settings() requires that all advertising flags are
also present in the supported flags, so make sure that is true.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This fixes a regression in 2.6.32: after resetting a 10Xpress PHY we
fail to reconfigure it if pause frames are enabled. Manually changing
pause frame settings will also fail.
Ben.
drivers/net/sfc/tenxpress.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sfc/tenxpress.c b/drivers/net/sfc/tenxpress.c
index 1a3495c..352cc56 100644
--- a/drivers/net/sfc/tenxpress.c
+++ b/drivers/net/sfc/tenxpress.c
@@ -752,6 +752,7 @@ tenxpress_get_settings(struct efx_nic *efx, struct ethtool_cmd *ecmd)
mdio45_ethtool_gset_npage(&efx->mdio, ecmd, adv, lpa);
+ ecmd->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
if (efx->phy_type != PHY_TYPE_SFX7101) {
ecmd->supported |= (SUPPORTED_100baseT_Full |
SUPPORTED_1000baseT_Full);
--
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: [PATCH net-2.6] sfc: 10Xpress: Report support for pause frames
From: Ben Hutchings @ 2009-10-22 22:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256250314.2785.22.camel@achroite>
On Thu, 2009-10-22 at 23:25 +0100, Ben Hutchings wrote:
> Commits 27fbc7d 'mdio: Expose pause frame advertising flags to ethtool'
> and c634263 'sfc: 10Xpress: Initialise pause advertising flags'
> added to our reported advertising flags.
>
> efx_mdio_set_settings() requires that all advertising flags are
> also present in the supported flags, so make sure that is true.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> This fixes a regression in 2.6.32: after resetting a 10Xpress PHY we
> fail to reconfigure it if pause frames are enabled. Manually changing
> pause frame settings will also fail.
Sorry, I was mistaken - those earlier commits are only in net-next-2.6,
so this is not needed for 2.6.32.
Ben.
--
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
* Re: NOHZ: local_softirq_pending 08
From: Tilman Schmidt @ 2009-10-22 23:37 UTC (permalink / raw)
To: Jarek Poplawski
Cc: David Miller, johannes, hidave.darkstar, linux-kernel, tglx,
linux-wireless, linux-ppp, netdev, paulus, isdn4linux,
i4ldeveloper, Karsten Keil
In-Reply-To: <4ADF5710.4030505@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
On 21.10.2009 20:46, /me wrote:
>>>> I have encountered the message in the subject during a test of
>>>> the Gigaset CAPI driver, and would like to determine whether
>>>> it's a bug in the driver, a bug somewhere else, or no bug at
>>>> all. The test scenario was PPP over ISDN with pppd+capiplugin.
>>>> In an alternative scenario, also PPP over ISDN but with
>>>> smpppd+capidrv, the message did not occur.
>
> I'm sorry, I had confused the two cases. The message occurs in
> the smpppd+capidrv scenario, not with pppd+capiplugin.
>
>>>> Johannes' answer pointed me to the netif_rx() function.
>>>> The Gigaset driver itself doesn't call that function at all.
>>>> In the scenario where I saw the message, it was the SYNC_PPP
>>>> line discipline that did.
>
> This analysis was therefore wrong. It would be the netif_rx()
> call towards the end of isdn_ppp_push_higher() in
> drivers/isdn/i4l/isdn_ppp.c L1177.
Having noticed that, I cooked up the following patch which fixed
the messages for me. Comments? (Adding i4l people to the already
impressive CC list.)
--- a/drivers/isdn/i4l/isdn_ppp.c
+++ b/drivers/isdn/i4l/isdn_ppp.c
@@ -1174,7 +1174,10 @@ isdn_ppp_push_higher(isdn_net_dev * net_dev, isdn_net_local * lp, struct sk_buff
#endif /* CONFIG_IPPP_FILTER */
skb->dev = dev;
skb_reset_mac_header(skb);
- netif_rx(skb);
+ if (in_interrupt())
+ netif_rx(skb);
+ else
+ netif_rx_ni(skb);
/* net_dev->local->stats.rx_packets++; done in isdn_net.c */
return;
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH] vmxnet3: remove duplicated #include
From: Shreyas Bhatewara @ 2009-10-22 23:58 UTC (permalink / raw)
To: netdev; +Cc: Huang Weiyi, Shreyas Bhatewara, pv-drivers
In-Reply-To: <alpine.LRH.2.00.0910221631580.23769@sbhatewara-dev1.eng.vmware.com>
Remove duplicate headerfile includes from vmxnet3_int.h
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Signed-off-by: Bhavesh Davda <davda@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 6bb9157..c4f8f04 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -27,15 +27,11 @@
#ifndef _VMXNET3_INT_H
#define _VMXNET3_INT_H
-#include <linux/types.h>
#include <linux/ethtool.h>
#include <linux/delay.h>
#include <linux/netdevice.h>
#include <linux/pci.h>
-#include <linux/ethtool.h>
#include <linux/compiler.h>
-#include <linux/module.h>
-#include <linux/moduleparam.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/ioport.h>
^ permalink raw reply related
* Re: [PATCH 2.6.32-rc5] r8169: fix Ethernet Hangup for RTL8110SC rev d
From: David Miller @ 2009-10-23 1:19 UTC (permalink / raw)
To: simon.wunderlich; +Cc: netdev, romieu, bernhard.schmidt
In-Reply-To: <66ae97b70910212348o6c32da21s906da4770ebc6f80@mail.gmail.com>
This patch looks fine, but I can't apply it because your email
client corrupted the patch, changing tab characters into
spaces, breaking up long lines, etc.
Please fix this up and resubmit, thanks. You can read
linux/Documentation/email-clients.txt for helpful tips.
^ permalink raw reply
* Re: [PATCH 0/3] netxen: bug fixes
From: David Miller @ 2009-10-23 1:28 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1256189943-20477-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Wed, 21 Oct 2009 22:39:00 -0700
> 3 bug fixes for 2.6.32. Please apply to net-2.6.
All applied, thank you.
^ permalink raw reply
* Re: [PATCH] isdn: fix possible circular locking dependency
From: David Miller @ 2009-10-23 1:28 UTC (permalink / raw)
To: xtfeng; +Cc: isdn, isdn4linux, tilman, netdev, linux-kernel
In-Reply-To: <1256202424-28314-1-git-send-email-xtfeng@gmail.com>
From: Xiaotian Feng <xtfeng@gmail.com>
Date: Thu, 22 Oct 2009 17:07:04 +0800
> There's a circular locking dependency:
...
> We don't need to lock nd->queue->xmit_lock to protect single
> isdn_net_lp_busy(). This can fix above lockdep warnings.
>
> Reported-and-tested-by: Tilman Schmidt <tilman@imap.cc>
> Signed-off-by: Xiaotian Feng <xtfeng@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6] sfc: 10Xpress: Report support for pause frames
From: David Miller @ 2009-10-23 1:31 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256250314.2785.22.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 22 Oct 2009 23:25:14 +0100
> Commits 27fbc7d 'mdio: Expose pause frame advertising flags to ethtool'
> and c634263 'sfc: 10Xpress: Initialise pause advertising flags'
> added to our reported advertising flags.
>
> efx_mdio_set_settings() requires that all advertising flags are
> also present in the supported flags, so make sure that is true.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6] sfc: 10Xpress: Report support for pause frames
From: David Miller @ 2009-10-23 1:35 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256250602.2785.25.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 22 Oct 2009 23:30:02 +0100
> Sorry, I was mistaken - those earlier commits are only in net-next-2.6,
> so this is not needed for 2.6.32.
Ok, I'll move the patch over to net-next-2.6 then, thanks.
^ permalink raw reply
* PATCH 23/10]Optimize the upload speed for PPP connection.
From: fangxiaozhi 00110321 @ 2009-10-23 1:48 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, zihan, greg, haegar
From: fangxiaozhi <huananhu@huawei.com>
1. This patch is based on the kernel of 2.6.32-rc4
2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
-----------------------------------------------------------------------------------------
--- a/drivers/net/ppp_async.c 2009-10-12 05:43:56.000000000 +0800
+++ b/drivers/net/ppp_async.c 2009-10-15 16:29:56.000000000 +0800
@@ -36,7 +36,7 @@
#define PPP_VERSION "2.4.2"
-#define OBUFSIZE 256
+#define OBUFSIZE 2048
/* Structure for storing local state. */
struct asyncppp {
******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
immediately and delete it!
*****************************************************************************************
^ permalink raw reply
* [net-2.6 PATCH] e1000e: reset the PHY on 82577/82578 when going to Sx
From: Jeff Kirsher @ 2009-10-23 2:53 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Bruce Allan, Jeff Kirsher
From: Bruce Allan <bruce.w.allan@intel.com>
The PHY on 82577/82578 parts needs a soft reset when transitioning to Sx
state in order for the PHY write which disables gigabit speed to take
effect. Gigabit speed must be disabled in order for the PHY writes to
registers on page 800 (the wakeup control registers) to work as expected
otherwise the system might not wake via WoL.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/ich8lan.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 99df2ab..aa0ab0e 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -2843,9 +2843,8 @@ void e1000e_disable_gig_wol_ich8lan(struct e1000_hw *hw)
E1000_PHY_CTRL_GBE_DISABLE;
ew32(PHY_CTRL, phy_ctrl);
- /* Workaround SWFLAG unexpectedly set during S0->Sx */
if (hw->mac.type == e1000_pchlan)
- udelay(500);
+ e1000_phy_hw_reset_ich8lan(hw);
default:
break;
}
^ permalink raw reply related
* [net-next-2.6 PATCH] e100: Fix to allow systems with FW based cards to resume from STD
From: Jeff Kirsher @ 2009-10-23 2:59 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, David Graham, Jeff Kirsher
From: David Graham <david.graham@intel.com>
Devices with loadable firmware must have their firmware reloaded
after the system resumes from sleep, but the request_firmare()
API is not available at this point in the resume flow because
tasks are not yet running, and the system will hang if it is
called. Work around this issue by only calling request_firmware()
for a device's first firmware load, and cache a copy of the pointer
to the firmware blob for that device, so that we may reload firmware
images even during resume.
Signed-off-by: David Graham <david.graham@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e100.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index ff83efd..f428c5f 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -621,6 +621,7 @@ struct nic {
u16 eeprom_wc;
__le16 eeprom[256];
spinlock_t mdio_lock;
+ const struct firmware *fw;
};
static inline void e100_write_flush(struct nic *nic)
@@ -1222,9 +1223,9 @@ static void e100_configure(struct nic *nic, struct cb *cb, struct sk_buff *skb)
static const struct firmware *e100_request_firmware(struct nic *nic)
{
const char *fw_name;
- const struct firmware *fw;
+ const struct firmware *fw = nic->fw;
u8 timer, bundle, min_size;
- int err;
+ int err = 0;
/* do not load u-code for ICH devices */
if (nic->flags & ich)
@@ -1240,12 +1241,20 @@ static const struct firmware *e100_request_firmware(struct nic *nic)
else /* No ucode on other devices */
return NULL;
- err = request_firmware(&fw, fw_name, &nic->pdev->dev);
+ /* If the firmware has not previously been loaded, request a pointer
+ * to it. If it was previously loaded, we are reinitializing the
+ * adapter, possibly in a resume from hibernate, in which case
+ * request_firmware() cannot be used.
+ */
+ if (!fw)
+ err = request_firmware(&fw, fw_name, &nic->pdev->dev);
+
if (err) {
DPRINTK(PROBE, ERR, "Failed to load firmware \"%s\": %d\n",
fw_name, err);
return ERR_PTR(err);
}
+
/* Firmware should be precisely UCODE_SIZE (words) plus three bytes
indicating the offsets for BUNDLESMALL, BUNDLEMAX, INTDELAY */
if (fw->size != UCODE_SIZE * 4 + 3) {
@@ -1268,7 +1277,10 @@ static const struct firmware *e100_request_firmware(struct nic *nic)
release_firmware(fw);
return ERR_PTR(-EINVAL);
}
- /* OK, firmware is validated and ready to use... */
+
+ /* OK, firmware is validated and ready to use. Save a pointer
+ * to it in the nic */
+ nic->fw = fw;
return fw;
}
^ permalink raw reply related
* [PATCH] net: use WARN() for the WARN_ON in commit b6b39e8f3fbbb
From: Arjan van de Ven @ 2009-10-23 3:35 UTC (permalink / raw)
To: herbert, netdev
>From d63ae5a34f2ed0821870c9e4c797e4e095f0c58a Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Thu, 22 Oct 2009 20:32:24 -0700
Subject: [PATCH] net: use WARN() for the WARN_ON in commit b6b39e8f3fbbb
Commit b6b39e8f3fbbb (tcp: Try to catch MSG_PEEK bug) added a printk()
to the WARN_ON() that's in tcp.c. This patch changes this combination
to WARN(); the advantage of WARN() is that the printk message shows up
inside the message, so that kerneloops.org will collect the message.
In addition, this gets rid of an extra if() statement.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
net/ipv4/tcp.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 90b2e06..a0e56db 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1442,9 +1442,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto found_ok_skb;
if (tcp_hdr(skb)->fin)
goto found_fin_ok;
- if (WARN_ON(!(flags & MSG_PEEK)))
- printk(KERN_INFO "recvmsg bug 2: copied %X "
- "seq %X\n", *seq, TCP_SKB_CB(skb)->seq);
+ WARN(!(flags & MSG_PEEK), KERN_INFO "recvmsg bug 2: "
+ "copied %X seq %X\n", *seq,
+ TCP_SKB_CB(skb)->seq);
}
/* Well, if we have backlog, try to process it now yet. */
--
1.6.2.5
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply related
* Re: [PATCH iproute2] ip: Support IFLA_TXQLEN in ip link command
From: Eric Dumazet @ 2009-10-23 4:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Netdev List
In-Reply-To: <4AE068EB.70005@gmail.com>
Eric Dumazet a écrit :
> We currently use an expensive ioctl() to get device txqueuelen, while
> rtnetlink gave it to us for free. This patch speeds up ip link operation
> when many devices are registered.
>
Here is a 2nd version od this patch, not displaying "qlen 0" useless info
[PATCH iproute2] ip: Support IFLA_TXQLEN in ip link show command
We currently use an expensive ioctl() to get device txqueuelen, while
rtnetlink gave it to us for free. This patch speeds up ip link operation
when many devices are registered.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 267ecb3..cadc1a3 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -131,26 +131,31 @@ static void print_operstate(FILE *f, __u8 state)
fprintf(f, "state %s ", oper_states[state]);
}
-static void print_queuelen(FILE *f, const char *name)
+static void print_queuelen(FILE *f, struct rtattr *tb[IFLA_MAX + 1])
{
- struct ifreq ifr;
- int s;
-
- s = socket(AF_INET, SOCK_STREAM, 0);
- if (s < 0)
- return;
-
- memset(&ifr, 0, sizeof(ifr));
- strcpy(ifr.ifr_name, name);
- if (ioctl(s, SIOCGIFTXQLEN, &ifr) < 0) {
- fprintf(f, "ioctl(SIOCGIFXQLEN) failed: %s\n", strerror(errno));
+ int qlen;
+
+ if (tb[IFLA_TXQLEN])
+ qlen = *(int *)RTA_DATA(tb[IFLA_TXQLEN]);
+ else {
+ struct ifreq ifr;
+ int s = socket(AF_INET, SOCK_STREAM, 0);
+
+ if (s < 0)
+ return;
+
+ memset(&ifr, 0, sizeof(ifr));
+ strcpy(ifr.ifr_name, (char *)RTA_DATA(tb[IFLA_IFNAME]));
+ if (ioctl(s, SIOCGIFTXQLEN, &ifr) < 0) {
+ fprintf(f, "ioctl(SIOCGIFXQLEN) failed: %s\n", strerror(errno));
+ close(s);
+ return;
+ }
close(s);
- return;
+ qlen = ifr.ifr_qlen;
}
- close(s);
-
- if (ifr.ifr_qlen)
- fprintf(f, "qlen %d", ifr.ifr_qlen);
+ if (qlen)
+ fprintf(f, "qlen %d", qlen);
}
static void print_linktype(FILE *fp, struct rtattr *tb)
@@ -253,7 +258,7 @@ int print_linkinfo(const struct sockaddr_nl *who,
print_operstate(fp, *(__u8 *)RTA_DATA(tb[IFLA_OPERSTATE]));
if (filter.showqueue)
- print_queuelen(fp, (char*)RTA_DATA(tb[IFLA_IFNAME]));
+ print_queuelen(fp, tb);
if (!filter.family || filter.family == AF_PACKET) {
SPRINT_BUF(b1);
^ permalink raw reply related
* Re: [net-2.6 PATCH] e1000e: reset the PHY on 82577/82578 when going to Sx
From: David Miller @ 2009-10-23 4:22 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091023025247.6750.89717.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 22 Oct 2009 19:53:00 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The PHY on 82577/82578 parts needs a soft reset when transitioning to Sx
> state in order for the PHY write which disables gigabit speed to take
> effect. Gigabit speed must be disabled in order for the PHY writes to
> registers on page 800 (the wakeup control registers) to work as expected
> otherwise the system might not wake via WoL.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* [PATCH iproute2] ip: speedup store_nlmsg()
From: Eric Dumazet @ 2009-10-23 4:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Netdev List
ip link show command has O(N^2) complexity, because it loops until list end.
Adding pointer to last elements avoids this loop.
Before patch :
# time ip -o link | wc
15013 240212 2136365
real 0m0.738s
user 0m0.770s
sys 0m0.035s
# time ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1e:0b:ec:d3:dc brd ff:ff:ff:ff:ff:ff
real 0m0.565s
user 0m0.540s
sys 0m0.025s
After patch :
# time ip/ip -o link | wc
15013 210192 2031310
real 0m0.189s
user 0m0.221s
sys 0m0.032s
# time ip/ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1e:0b:ec:d3:dc brd ff:ff:ff:ff:ff:ff
real 0m0.032s
user 0m0.006s
sys 0m0.026s
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index cadc1a3..7674256 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -570,13 +570,16 @@ static int print_selected_addrinfo(int ifindex, struct nlmsg_list *ainfo, FILE *
return 0;
}
+struct nlmsg_list_info {
+ struct nlmsg_list *first;
+ struct nlmsg_list *last;
+};
static int store_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
void *arg)
{
- struct nlmsg_list **linfo = (struct nlmsg_list**)arg;
+ struct nlmsg_list_info *linfo = (struct nlmsg_list_info *)arg;
struct nlmsg_list *h;
- struct nlmsg_list **lp;
h = malloc(n->nlmsg_len+sizeof(void*));
if (h == NULL)
@@ -585,8 +588,11 @@ static int store_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
memcpy(&h->h, n, n->nlmsg_len);
h->next = NULL;
- for (lp = linfo; *lp; lp = &(*lp)->next) /* NOTHING */;
- *lp = h;
+ if (linfo->first)
+ linfo->last->next = h;
+ else
+ linfo->first = h;
+ linfo->last = h;
ll_remember_index(who, n, NULL);
return 0;
@@ -594,8 +600,8 @@ static int store_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
static int ipaddr_list_or_flush(int argc, char **argv, int flush)
{
- struct nlmsg_list *linfo = NULL;
- struct nlmsg_list *ainfo = NULL;
+ struct nlmsg_list_info linfo = {0};
+ struct nlmsg_list_info ainfo = {0};
struct nlmsg_list *l, *n;
char *filter_dev = NULL;
int no_link = 0;
@@ -750,7 +756,7 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
if (filter.family && filter.family != AF_PACKET) {
struct nlmsg_list **lp;
- lp=&linfo;
+ lp = &linfo.first;
if (filter.oneline)
no_link = 1;
@@ -760,7 +766,7 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
struct ifinfomsg *ifi = NLMSG_DATA(&l->h);
struct nlmsg_list *a;
- for (a=ainfo; a; a=a->next) {
+ for (a = ainfo.first; a; a = a->next) {
struct nlmsghdr *n = &a->h;
struct ifaddrmsg *ifa = NLMSG_DATA(n);
@@ -807,12 +813,12 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
}
}
- for (l=linfo; l; l = n) {
+ for (l = linfo.first; l; l = n) {
n = l->next;
if (no_link || print_linkinfo(NULL, &l->h, stdout) == 0) {
struct ifinfomsg *ifi = NLMSG_DATA(&l->h);
if (filter.family != AF_PACKET)
- print_selected_addrinfo(ifi->ifi_index, ainfo, stdout);
+ print_selected_addrinfo(ifi->ifi_index, ainfo.first, stdout);
}
fflush(stdout);
free(l);
^ permalink raw reply related
* Re: [PATCH] net: use WARN() for the WARN_ON in commit b6b39e8f3fbbb
From: David Miller @ 2009-10-23 4:38 UTC (permalink / raw)
To: arjan; +Cc: herbert, netdev
In-Reply-To: <20091022203512.1d714d5a@infradead.org>
From: Arjan van de Ven <arjan@infradead.org>
Date: Thu, 22 Oct 2009 20:35:12 -0700
> Commit b6b39e8f3fbbb (tcp: Try to catch MSG_PEEK bug) added a printk()
> to the WARN_ON() that's in tcp.c. This patch changes this combination
> to WARN(); the advantage of WARN() is that the printk message shows up
> inside the message, so that kerneloops.org will collect the message.
>
> In addition, this gets rid of an extra if() statement.
>
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][RESEND] myri10ge: improve port type reporting in ethtool
From: David Miller @ 2009-10-23 4:43 UTC (permalink / raw)
To: brice; +Cc: netdev, bhutchings
In-Reply-To: <4ADD5702.80804@myri.com>
From: Brice Goglin <brice@myri.com>
Date: Tue, 20 Oct 2009 08:21:54 +0200
> Improve the reporting of myri10ge port type in ethtool,
> and update for new boards.
>
> Signed-off-by: Brice Goglin <brice@myri.com>
> Signed-off-by: Andrew Gallatin <gallatin@myri.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Fix RPF to work with policy routing
From: David Miller @ 2009-10-23 4:49 UTC (permalink / raw)
To: hadi; +Cc: netdev, atis, eric.dumazet, zenczykowski
In-Reply-To: <1255868019.4815.27.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Sun, 18 Oct 2009 08:13:39 -0400
> On Sun, 2009-10-18 at 08:12 -0400, jamal wrote:
>> policy routing never worked with mark.
>
> I meant policy routing, mark and RPF never worked together ;->
Is this actually valid?
Such a change has a built-in assumption, I think, that
marks are symmetric.
Just because we ended up with mark X on input doesn't mean
that the reverse path route exists with mark X too.
In fact I can't even see a valid way to specify a mark for
the RPF lookup.
Maybe you can convince me otherwise :-)
^ permalink raw reply
* VLAN and ARP failure on tg3 drivers
From: Gertjan Hofman @ 2009-10-23 4:52 UTC (permalink / raw)
To: netdev
Dear Kernel developers,
A couple of weeks ago we tried to migrate from a 2.6.24 kernel to a 2.6.29 kernel and noticed our VLAN application no longer works. The problem is easy to replicate:
1. connect 2 PC's with a cross-over cable
2. set up a fixed IP address to both PC's (say 192.168.0.[1,2])
3. create a vlan: vconfig add eth0 0.
4. set IP addresses on the VLAN devices (say 192.168.1.[1,2])
5. try ping one machine from the other.
I tried to dig into the problem by using un-patched kernel.org kernels with Ubuntu .config files. Kernels up to 2.6.26 work fine, kernels after and including 2.6.27 fail. The problem is that ARP messages are being dropped. If the ARP table is updated by hand on each machine, the communication across the VLAN works fine.
At first I thought the kernel VLAN code was the problem (we had an earlier issue with a regression in 2.6.24) but it looks like the problem is actually with the tg3 driver. Our system uses Broadcom ethernet chips. I tried the same experiments with combination of boards that have Broadcom and none-Broadcom and the only time I see it fail is with the tg3 driver loaded.
Snooping with WireShark shows that a ARP request from the non-Broadcom machine is seen and even answered, but never appears back on the network. If the Broadcom machine orginates the ARP message, it never arrives at the destination. I tried lowering the size of the MTU to 1492 as well as giving each VLAN device a different MAC. No deal.
I tried to look at tg3 patch changes from 2.6.26 to 2.6.27 but I am not familiar enough with the Git system to extract the appropiate changes. I am a bit surprised that I am not seeing any references to this on the web, the combination of >2.6.27 kernels, Broadcom and VLAN cant be that uncommon.
I would be happy to provide more information and to try tests if any one can suggest them.
Sincerely,
Gertjan
^ permalink raw reply
* Re: [PATCH] ifb: should not use __dev_get_by_index() without locks
From: David Miller @ 2009-10-23 4:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADDAEA6.2040903@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Oct 2009 14:35:50 +0200
> [PATCH] ifb: should not use __dev_get_by_index() without locks
>
> At this point (ri_tasklet()), RTNL or dev_base_lock are not held,
> we must use dev_get_by_index() instead of __dev_get_by_index()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC][PATCH] pkt_sched: skbedit add support for setting mark
From: David Miller @ 2009-10-23 4:57 UTC (permalink / raw)
To: hadi; +Cc: denys, alexander.h.duyck, netdev
In-Reply-To: <1255612159.5033.1.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Thu, 15 Oct 2009 09:09:18 -0400
> On Wed, 2009-10-14 at 15:08 -0700, David Miller wrote:
>
>> This patch doesn't apply.
>
> Ok, Ive tested this on a separate machine - it applies and compiles.
Applied, thanks Jamal.
^ permalink raw reply
* Re: VLAN and ARP failure on tg3 drivers
From: Eric Dumazet @ 2009-10-23 5:23 UTC (permalink / raw)
To: Gertjan Hofman; +Cc: netdev
In-Reply-To: <93821.71108.qm@web32607.mail.mud.yahoo.com>
Gertjan Hofman a écrit :
> Dear Kernel developers,
>
> A couple of weeks ago we tried to migrate from a 2.6.24 kernel to a 2.6.29 kernel and noticed our VLAN application no longer works. The problem is easy to replicate:
>
> 1. connect 2 PC's with a cross-over cable
> 2. set up a fixed IP address to both PC's (say 192.168.0.[1,2])
> 3. create a vlan: vconfig add eth0 0.
> 4. set IP addresses on the VLAN devices (say 192.168.1.[1,2])
> 5. try ping one machine from the other.
>
> I tried to dig into the problem by using un-patched kernel.org kernels with Ubuntu .config files. Kernels up to 2.6.26 work fine, kernels after and including 2.6.27 fail. The problem is that ARP messages are being dropped. If the ARP table is updated by hand on each machine, the communication across the VLAN works fine.
>
> At first I thought the kernel VLAN code was the problem (we had an earlier issue with a regression in 2.6.24) but it looks like the problem is actually with the tg3 driver. Our system uses Broadcom ethernet chips. I tried the same experiments with combination of boards that have Broadcom and none-Broadcom and the only time I see it fail is with the tg3 driver loaded.
>
> Snooping with WireShark shows that a ARP request from the non-Broadcom machine is seen and even answered, but never appears back on the network. If the Broadcom machine orginates the ARP message, it never arrives at the destination. I tried lowering the size of the MTU to 1492 as well as giving each VLAN device a different MAC. No deal.
>
> I tried to look at tg3 patch changes from 2.6.26 to 2.6.27 but I am not familiar enough with the Git system to extract the appropiate changes. I am a bit surprised that I am not seeing any references to this on the web, the combination of >2.6.27 kernels, Broadcom and VLAN cant be that uncommon.
>
> I would be happy to provide more information and to try tests if any one can suggest them.
>
> Sincerely,
>
> Gertjan
Hello Gertjan
I'll take a look at this problem and try to reproduce it, but I use VLAN + tg3 +
bonding without noticing a regression yet.
Only difference is I use "ip link add link" command to setup VLANS, not vconfig,
a bit deprecated.
Could you try something like this setup
ip link set eth1 up
ip link add link eth1 vlan.103 type vlan id 103
ip addr add 192.168.20.110/24 dev vlan.103
ip link set vlan.103 up
^ 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