* Re: [PATCH] check the return value of ndo_select_queue()
From: Eric Dumazet @ 2009-11-14 12:37 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <412e6f7f0911140414x4918d8d2teb60ee585ebdfce9@mail.gmail.com>
Changli Gao a écrit :
>
> It seems better than mime.
>
>
Well, it's still your patch :)
^ permalink raw reply
* Re: [PATCH] check the return value of ndo_select_queue()
From: Changli Gao @ 2009-11-14 12:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <4AFE621C.1020004@gmail.com>
On Sat, Nov 14, 2009 at 3:54 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> Please always use scripts/checkpatch.pl before sending patches
>
> } else if((select_queue = dev->netdev_ops->ndo_select_queue)) {
>
> A space is required after the "if"
>
Thanks.
> It seems to me this patch is not matching its ChangeLog :
>
> You moved the :
>
> if (sk && sk->sk_dst_cache)
> sk_tx_queue_set(sk, queue_index);
Maybe I did more in my patch, but I think these little changes doesn't
need separate patches.
>
> Why not using much readable patch like :
>
>
> [PATCH] check the return value of ndo_select_queue()
>
> check the return value of ndo_select_queue()
>
> Check the return value of ndo_select_queue(). If the value isn't smaller
> than the real_num_tx_queues, print a warning message, and reset it to zero.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ----
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index ad8e320..bbc9a41 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1845,6 +1845,20 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
> }
> EXPORT_SYMBOL(skb_tx_hash);
>
> +static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index)
> +{
> + if (unlikely(queue_index >= dev->real_num_tx_queues)) {
> + if (net_ratelimit()) {
> + WARN(1, "%s selects TX queue %d, but "
> + "real number of TX queues is %d\n",
> + dev->name, queue_index,
> + dev->real_num_tx_queues);
> + }
> + return 0;
> + }
> + return queue_index;
> +}
> +
> static struct netdev_queue *dev_pick_tx(struct net_device *dev,
> struct sk_buff *skb)
> {
> @@ -1858,6 +1872,7 @@ static struct netdev_queue *dev_pick_tx(struct net_device *dev,
>
> if (ops->ndo_select_queue) {
> queue_index = ops->ndo_select_queue(dev, skb);
> + queue_index = dev_cap_txqueue(dev, queue_index);
> } else {
> queue_index = 0;
> if (dev->real_num_tx_queues > 1)
>
>
>
It seems better than mime.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 10:19 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <4AFE7F15.1080504@gmail.com>
Eric Dumazet a écrit :
> Ang Way Chuang a écrit :
>> I assume that ip route .... advmss achieves that effect? I tried it,
>> but it doesn't work.
>>
>
> It should. Please provide your kernel version and what you tried exactly.
>
>
Here a tcpdump of an iperf -M 120 session on current net-next-2.6 kernel
iperf -M 120 -c 192.168.0.1 -m
WARNING: attempt to set TCP maximum segment size to 120, but got 536
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.2 port 48178 connected with 192.168.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 26.4 MBytes 22.1 Mbits/sec
[ 3] MSS size 108 bytes (MTU 148 bytes, unknown interface)
hints :
1) Use iperf -M 120 flag on both sides
2) disable tso/gso on sender
ethtool -K eth0 tso off gso off
11:15:17.052202 IP 192.168.0.2.48177 > 192.168.0.1.5001: S 3914872183:3914872183(0) win 480 <mss 120,nop,nop,timestamp 63768988 0,nop,wscale 6>
11:15:17.052291 IP 192.168.0.1.5001 > 192.168.0.2.48177: S 2771326659:2771326659(0) ack 3914872184 win 432 <mss 120,nop,nop,timestamp 580923920 63768988,nop,wscale 6>
11:15:17.052494 IP 192.168.0.2.48177 > 192.168.0.1.5001: . ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052514 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1:25(24) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052532 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 25:133(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052534 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 133:241(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052537 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 241:349(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923920>
11:15:17.052612 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 25 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052621 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 349:457(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052624 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 133 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052629 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 457:565(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052631 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 349 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052635 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 565:673(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052638 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 673:781(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052711 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 565 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052715 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 781:889(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052718 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 889:997(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052720 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 781 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052724 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 997:1105(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052727 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1105:1213(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052804 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 997 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052813 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1213:1321(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052816 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1321:1429(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052823 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1213 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052827 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1429:1537(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052829 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1537:1645(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052901 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1429 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052910 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1645:1753(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052913 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1753:1861(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052914 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1645 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052917 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 1861:1969(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052920 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 1969:2077(108) ack 1 win 8 <nop,nop,timestamp 63768988 580923921>
11:15:17.052990 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 1861 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.052996 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 2077:2185(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
11:15:17.052999 IP 192.168.0.2.48177 > 192.168.0.1.5001: P 2185:2293(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
11:15:17.053001 IP 192.168.0.1.5001 > 192.168.0.2.48177: . ack 2077 win 7 <nop,nop,timestamp 580923921 63768988>
11:15:17.053005 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 2293:2401(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
11:15:17.053008 IP 192.168.0.2.48177 > 192.168.0.1.5001: . 2401:2509(108) ack 1 win 8 <nop,nop,timestamp 63768989 580923921>
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 9:57 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <51d384e10911140124g285621a5n54afa1bdb1b02997@mail.gmail.com>
Ang Way Chuang a écrit :
> I assume that ip route .... advmss achieves that effect? I tried it,
> but it doesn't work.
>
It should. Please provide your kernel version and what you tried exactly.
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Ang Way Chuang @ 2009-11-14 9:24 UTC (permalink / raw)
To: Eric Dumazet, netdev
In-Reply-To: <4AFE748C.3050100@gmail.com>
I assume that ip route .... advmss achieves that effect? I tried it,
but it doesn't work.
On Sat, Nov 14, 2009 at 5:12 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Eric Dumazet a écrit :
>>
>> Oh well, this reminds me TCP_MAXSEG doesnt work as expected...
>
> Oops, this problem I had few years ago was fixed last year in 2.6.27, sorry ...
>
> commit f5fff5dc8a7a3f395b0525c02ba92c95d42b7390
> Author: Tom Quetchenbach <virtualphtn@gmail.com>
> Date: Sun Sep 21 00:21:51 2008 -0700
>
> tcp: advertise MSS requested by user
>
> I'm trying to use the TCP_MAXSEG option to setsockopt() to set the MSS
> for both sides of a bidirectional connection.
>
> man tcp says: "If this option is set before connection establishment, it
> also changes the MSS value announced to the other end in the initial
> packet."
>
> However, the kernel only uses the MTU/route cache to set the advertised
> MSS. That means if I set the MSS to, say, 500 before calling connect(),
> I will send at most 500-byte packets, but I will still receive 1500-byte
> packets in reply.
>
> This is a bug, either in the kernel or the documentation.
>
> This patch (applies to latest net-2.6) reduces the advertised value to
> that requested by the user as long as setsockopt() is called before
> connect() or accept(). This seems like the behavior that one would
> expect as well as that which is documented.
>
> I've tried to make sure that things that depend on the advertised MSS
> are set correctly.
>
> Signed-off-by: Tom Quetchenbach <virtualphtn@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
>
>
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 9:12 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <4AFE6FF0.3030101@gmail.com>
Eric Dumazet a écrit :
>
> Oh well, this reminds me TCP_MAXSEG doesnt work as expected...
Oops, this problem I had few years ago was fixed last year in 2.6.27, sorry ...
commit f5fff5dc8a7a3f395b0525c02ba92c95d42b7390
Author: Tom Quetchenbach <virtualphtn@gmail.com>
Date: Sun Sep 21 00:21:51 2008 -0700
tcp: advertise MSS requested by user
I'm trying to use the TCP_MAXSEG option to setsockopt() to set the MSS
for both sides of a bidirectional connection.
man tcp says: "If this option is set before connection establishment, it
also changes the MSS value announced to the other end in the initial
packet."
However, the kernel only uses the MTU/route cache to set the advertised
MSS. That means if I set the MSS to, say, 500 before calling connect(),
I will send at most 500-byte packets, but I will still receive 1500-byte
packets in reply.
This is a bug, either in the kernel or the documentation.
This patch (applies to latest net-2.6) reduces the advertised value to
that requested by the user as long as setsockopt() is called before
connect() or accept(). This seems like the behavior that one would
expect as well as that which is documented.
I've tried to make sure that things that depend on the advertised MSS
are set correctly.
Signed-off-by: Tom Quetchenbach <virtualphtn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: TCP throughput drops sharply around MTU of 180 bytes
From: Eric Dumazet @ 2009-11-14 8:53 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev
In-Reply-To: <51d384e10911140028r76e1aefei3a224b5c542d82e8@mail.gmail.com>
Ang Way Chuang a écrit :
> Hi kernel networking gurus,
>
> I came across a situation where I need to evaluate the packing
> efficiency of
> small packets. Because TCP is byte oriented protocol, there is no way
> to force it
> to generate small packets, so I forced it by adjusting MTU.
>
> However, through the experiment, I found that measured throughput
> of TCP stream dropped significantly if MTU is set to value less than 180 bytes.
> At first, I thought it must be some bugs on my code. So, I decided to repeat
> the test over a dedicated 10Mbps Ethernet link. The results that I measured
> over Ethernet is shown below:
>
>
> MTU Throughput (Mbps)
> ----- --------------
> 181 4.50
> 180 4.39
> 179 3.05
> 178 3.04
>
> I used iperf throughout the tests. Can someone enlighten me on this matter?
> Why the throughput drops sharply if MTU is less than 180 bytes? Is there some
> special meaning associated with 180 that I don't know of?
>
> Some basic information about my system:
> kernel version: 2.6.27.5-117.fc10.x86_64
> distro: fedora 10
> CPU: Pentium 4 3.00 GHz
>
> Should you need more information, I shall gladly cooperate. Please keep me
> in the loop because it is hard for me to cop with the volume of emails on netdev
> mailing list.
>
Oh well, this reminds me TCP_MAXSEG doesnt work as expected...
^ permalink raw reply
* TCP throughput drops sharply around MTU of 180 bytes
From: Ang Way Chuang @ 2009-11-14 8:48 UTC (permalink / raw)
To: netdev
Hi kernel networking gurus,
I came across a situation where I need to evaluate the packing
efficiency of small packets. Because TCP is byte oriented protocol,
there is no way
to force it to generate small packets, so I forced it by adjusting MTU.
However, through the experiment, I found that measured throughput
of TCP stream dropped significantly if MTU is set to value less than 180 bytes.
At first, I thought it must be some bugs on my code. So, I decided to repeat
the test over a dedicated 10Mbps Ethernet link. The results that I measured
over Ethernet is shown below:
MTU Throughput (Mbps)
----- --------------
181 4.50
180 4.39
179 3.05
178 3.04
I used iperf throughout the tests. Can someone enlighten me on this matter?
Why the throughput drops sharply if MTU is less than 180 bytes? Is there some
special meaning associated with 180 that I don't know of?
Some basic information about my system:
kernel version: 2.6.27.5-117.fc10.x86_64
distro: fedora 10
CPU: Pentium 4 3.00 GHz
Should you need more information, I shall gladly cooperate. Please keep me
in the loop because it is hard for me to cop with the volume of emails on netdev
mailing list.
Thank you in advance.
Regards,
Ang Way Chuang
^ permalink raw reply
* [PATCH] forcedeth: mac address fix
From: Stanislav O. Bezzubtsev @ 2009-11-14 8:31 UTC (permalink / raw)
Cc: davem, aabdulla, yinghai, netdev, linux-kernel,
Stanislav O. Bezzubtsev
Use the existing random_ether_addr() to generate random MAC
instead of doing it by-hand.
Signed-off-by: Stanislav O. Bezzubtsev <stas@lvk.cs.msu.su>
---
drivers/net/forcedeth.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index e1da466..3116601 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5821,10 +5821,7 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
dev->dev_addr);
dev_printk(KERN_ERR, &pci_dev->dev,
"Please complain to your hardware vendor. Switching to a random MAC.\n");
- dev->dev_addr[0] = 0x00;
- dev->dev_addr[1] = 0x00;
- dev->dev_addr[2] = 0x6c;
- get_random_bytes(&dev->dev_addr[3], 3);
+ random_ether_addr(dev->dev_addr);
}
dprintk(KERN_DEBUG "%s: MAC Address %pM\n",
--
1.6.5
^ permalink raw reply related
* TCP throughput drops sharply around MTU of 180 bytes
From: Ang Way Chuang @ 2009-11-14 8:28 UTC (permalink / raw)
To: netdev
Hi kernel networking gurus,
I came across a situation where I need to evaluate the packing
efficiency of
small packets. Because TCP is byte oriented protocol, there is no way
to force it
to generate small packets, so I forced it by adjusting MTU.
However, through the experiment, I found that measured throughput
of TCP stream dropped significantly if MTU is set to value less than 180 bytes.
At first, I thought it must be some bugs on my code. So, I decided to repeat
the test over a dedicated 10Mbps Ethernet link. The results that I measured
over Ethernet is shown below:
MTU Throughput (Mbps)
----- --------------
181 4.50
180 4.39
179 3.05
178 3.04
I used iperf throughout the tests. Can someone enlighten me on this matter?
Why the throughput drops sharply if MTU is less than 180 bytes? Is there some
special meaning associated with 180 that I don't know of?
Some basic information about my system:
kernel version: 2.6.27.5-117.fc10.x86_64
distro: fedora 10
CPU: Pentium 4 3.00 GHz
Should you need more information, I shall gladly cooperate. Please keep me
in the loop because it is hard for me to cop with the volume of emails on netdev
mailing list.
Thank you in advance.
Regards,
Ang Way Chuang
^ permalink raw reply
* Re: [rfc 0/4] igb: bandwidth allocation
From: Jeff Kirsher @ 2009-11-14 8:01 UTC (permalink / raw)
To: Simon Horman; +Cc: e1000-devel, netdev, Arnd Bergmann
In-Reply-To: <20091105022123.GA22019@verge.net.au>
On Wed, Nov 4, 2009 at 18:21, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Nov 04, 2009 at 05:46:50PM -0800, Jeff Kirsher wrote:
>> On Wed, Nov 4, 2009 at 16:58, Simon Horman <horms@verge.net.au> wrote:
>> > Hi,
>> >
>> > this series of patches exposes the bandwidth allocation
>> > hardware support of the Intel 82576. It does so through
>> > a rather hackish sysfs entry. That interface is just intended
>> > for testing so that the exposed hardware feature can
>> > be exercised. I would like to find a generic way to expose
>> > this feature to user-space.
>> >
>>
>> Thanks Simon. I have add the 4 patch series to my tree for testing.
>
> Thanks. I wanted to get the code out rather than sitting on it
> for lack of a better user-space interface. Although there
> is a lot of fluff the actual register twiddling for
> bandwidth allocation turned out to be quite simple.
>
Simon -
After doing some testing on the series of patches, we are getting a
panic with these patches applied to net-next. I have provided below
the panic we saw, right now we have a large patch load so a bisect
will have to wait. Hopefully with time permitting, we will be able to
revisit these patches soon.
igbvf 0000:02:10.0: PF still resetting
igbvf 0000:02:10.2: PF still resetting
igbvf 0000:02:10.4: PF still resetting
igbvf 0000:02:10.6: PF still resetting
igbvf 0000:02:11.0: PF still resetting
igbvf 0000:02:11.2: PF still resetting
igbvf 0000:02:11.4: PF still resetting
igbvf 0000:02:10.1: PF still resetting
igbvf 0000:02:10.3: PF still resetting
igbvf 0000:02:10.5: PF still resetting
igbvf 0000:02:10.7: PF still resetting
igbvf 0000:02:11.1: PF still resetting
igbvf 0000:02:11.3: PF still resetting
igbvf 0000:02:11.5: PF still resetting
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffffa0087d3c>] igb_xmit_frame_ring_adv+0x1d/0x71a [igb] PGD 0
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file:
/sys/bus/pci/slots/1-1/address CPU 1 Modules linked in: igbvf igb ipv6
autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table video output
sbs sbshc joydev e1000e e1000 i2c_i801 shpchp i2c_core pcspkr iTCO_wdt
iTCO_vendor_support usb_storage [last unloaded: igb]
Pid: 52, comm: events/1 Not tainted 2.6.32-rc3-net-next-vf-tag111109 #1 S5520HC
RIP: 0010:[<ffffffffa0087d3c>] [<ffffffffa0087d3c>]
igb_xmit_frame_ring_adv+0x1d/0x71a [igb]
RSP: 0018:ffff8801f8803aa0 EFLAGS: 00010286
RAX: 0000000000000001 RBX: 0000000000000600 RCX: 0000000000000000
RDX: ffff8803609e4700 RSI: 0000000000000000 RDI: ffff88036559d500
RBP: ffff8801f8803b10 R08: 0000000000000000 R09: ffff8801f8994018
R10: ffff88036559d500 R11: ffffffff81e9caf8 R12: ffff88036559d500
R13: ffff88036559d500 R14: 0000000000000000 R15: ffff88036791a4c0
FS: 0000000000000000(0000) GS:ffff8801f8800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 0000000001001000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/1 (pid: 52, threadinfo ffff8801e91a6000, task
ffff8801e91abfc0)
Stack:
ffff8801e91abfc0 0000000000000000 0000000000000001 0000000000000000
<0> ffff8801f8803b20 0000000000000246 0000000000000000
ffffffff812f7558 <0> ffff880100000000 ffff8803609f4e00
ffff88036559d500 ffff8803609e4000 Call Trace:
<IRQ>
[<ffffffff812f7558>] ? __netif_tx_lock+0x16/0x1f
[<ffffffffa008c130>] igb_xmit_frame_adv+0x3a/0x3c [igb]
[<ffffffff812e55d7>] dev_hard_start_xmit+0x1d1/0x27e
[<ffffffff812f7cc2>] sch_direct_xmit+0x68/0x14e [<ffffffff812e59bd>]
dev_queue_xmit+0x22e/0x378 [<ffffffff812e588d>] ?
dev_queue_xmit+0xfe/0x378 [<ffffffff8104b565>] ?
_local_bh_enable_ip+0x9c/0xa7 [<ffffffff812eb72c>]
neigh_resolve_output+0x1f0/0x225 [<ffffffffa013a3be>]
ip6_output_finish+0x6f/0xd6 [ipv6] [<ffffffffa013adbb>]
ip6_output2+0x328/0x337 [ipv6] [<ffffffffa013bcce>]
ip6_output+0xf04/0xf28 [ipv6] [<ffffffffa01547af>] dst_output+0xb/0xd
[ipv6] [<ffffffffa0155ea7>] mld_sendpack+0x2aa/0x48f [ipv6]
[<ffffffffa0157001>] mld_ifc_timer_expire+0x1c8/0x201 [ipv6]
[<ffffffffa0156e39>] ? mld_ifc_timer_expire+0x0/0x201 [ipv6]
[<ffffffff81051667>] run_timer_softirq+0x1b0/0x26b
[<ffffffff810515da>] ? run_timer_softirq+0x123/0x26b
[<ffffffff8106681b>] ? ktime_get+0x73/0x8e [<ffffffff8106a79e>] ?
tick_dev_program_event+0x2a/0x9c [<ffffffff8104bcf1>]
__do_softirq+0xd5/0x19d [<ffffffff8100cc9c>] call_softirq+0x1c/0x34
[<ffffffff8100e2d8>] do_softirq+0x33/0x6b [<ffffffff8104b959>]
irq_exit+0x36/0x8a [<ffffffff81020129>]
smp_apic_timer_interrupt+0x78/0x87
[<ffffffff8100c673>] apic_timer_interrupt+0x13/0x20 <EOI>
[<ffffffff8130dec4>] ? rt_cache_flush+0x154/0x169
[<ffffffff8133feeb>] ? fib_netdev_event+0x84/0x8b
[<ffffffff81382b1c>] ? notifier_call_chain+0x33/0x5b
[<ffffffff812f0fd5>] ? linkwatch_event+0x0/0x31 [<ffffffff81062679>]
? __raw_notifier_call_chain+0x9/0xb [<ffffffff8106268a>] ?
raw_notifier_call_chain+0xf/0x11 [<ffffffff812e5b9d>] ?
call_netdevice_notifiers+0x16/0x18
--
Cheers,
Jeff
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply
* Re: [PATCH] check the return value of ndo_select_queue()
From: Eric Dumazet @ 2009-11-14 7:54 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <412e6f7f0911131650j6d13f95bt20aa607f9f44c3af@mail.gmail.com>
Changli Gao a écrit :
> check the return value of ndo_select_queue()
>
> Check the return value of ndo_select_queue(). If the value isn't smaller
> than the real_num_tx_queues, print a warning message, and reset it to zero.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
> net/core/dev.c | 33 ++++++++++++++++++++++++---------
> 1 file changed, 24 insertions(+), 9 deletions(-)
> diff --git a/net/core/dev.c b/net/core/dev.c
> index bf629ac..74a3824 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1849,22 +1849,37 @@ static struct netdev_queue *dev_pick_tx(struct
> net_device *dev,
> {
> u16 queue_index;
> struct sock *sk = skb->sk;
> + unsigned int real_num_tx_queues = dev->real_num_tx_queues;
>
> if (sk_tx_queue_recorded(sk)) {
> queue_index = sk_tx_queue_get(sk);
> + if (unlikely(queue_index >= real_num_tx_queues)) {
> + do {
> + queue_index -= real_num_tx_queues;
> + } while (queue_index >= real_num_tx_queues);
> + sk_tx_queue_set(sk, queue_index);
> + }
> } else {
> - const struct net_device_ops *ops = dev->netdev_ops;
> + u16 (*select_queue)(struct net_device *, struct sk_buff *);
>
> - if (ops->ndo_select_queue) {
> - queue_index = ops->ndo_select_queue(dev, skb);
> - } else {
> + if (real_num_tx_queues == 1) {
> queue_index = 0;
> - if (dev->real_num_tx_queues > 1)
> - queue_index = skb_tx_hash(dev, skb);
> -
> - if (sk && sk->sk_dst_cache)
> - sk_tx_queue_set(sk, queue_index);
> + } else if((select_queue = dev->netdev_ops->ndo_select_queue)) {
> + queue_index = select_queue(dev, skb);
> + if (unlikely(queue_index >= real_num_tx_queues)) {
> + if (net_ratelimit())
> + WARN(1, "%s selects TX queue %d, but "
> + "real number of TX queues is %d\n",
> + dev->name, queue_index,
> + real_num_tx_queues);
> + queue_index = 0;
> + }
> + } else {
> + queue_index = skb_tx_hash(dev, skb);
> }
> +
> + if (sk && sk->sk_dst_cache)
> + sk_tx_queue_set(sk, queue_index);
> }
>
> skb_set_queue_mapping(skb, queue_index);
Please always use scripts/checkpatch.pl before sending patches
} else if((select_queue = dev->netdev_ops->ndo_select_queue)) {
A space is required after the "if"
It seems to me this patch is not matching its ChangeLog :
You moved the :
if (sk && sk->sk_dst_cache)
sk_tx_queue_set(sk, queue_index);
Why not using much readable patch like :
[PATCH] check the return value of ndo_select_queue()
check the return value of ndo_select_queue()
Check the return value of ndo_select_queue(). If the value isn't smaller
than the real_num_tx_queues, print a warning message, and reset it to zero.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
----
diff --git a/net/core/dev.c b/net/core/dev.c
index ad8e320..bbc9a41 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1845,6 +1845,20 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
}
EXPORT_SYMBOL(skb_tx_hash);
+static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index)
+{
+ if (unlikely(queue_index >= dev->real_num_tx_queues)) {
+ if (net_ratelimit()) {
+ WARN(1, "%s selects TX queue %d, but "
+ "real number of TX queues is %d\n",
+ dev->name, queue_index,
+ dev->real_num_tx_queues);
+ }
+ return 0;
+ }
+ return queue_index;
+}
+
static struct netdev_queue *dev_pick_tx(struct net_device *dev,
struct sk_buff *skb)
{
@@ -1858,6 +1872,7 @@ static struct netdev_queue *dev_pick_tx(struct net_device *dev,
if (ops->ndo_select_queue) {
queue_index = ops->ndo_select_queue(dev, skb);
+ queue_index = dev_cap_txqueue(dev, queue_index);
} else {
queue_index = 0;
if (dev->real_num_tx_queues > 1)
^ permalink raw reply related
* Re: [RFC] vlan: GRO rx statistics
From: Eric Dumazet @ 2009-11-14 7:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <20091114012741.GA18764@gondor.apana.org.au>
Herbert Xu a écrit :
> On Fri, Nov 13, 2009 at 05:41:21PM +0100, Eric Dumazet wrote:
>> Replying to myself, I found root of the problem and posted a fix.
>
> Just curious, do you have a link to that fix?
>
Sure, I thought you were a netdev subscriber, sorry :)
[PATCH net-next-2.6] vlan: Use __vlan_hwaccel_put_tag() in rx
http://patchwork.ozlabs.org/patch/38377/
>> Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...
>
> Well making it per-napi_struct should do the trick.
>
> Cheers,
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Eric Dumazet @ 2009-11-14 7:21 UTC (permalink / raw)
To: Benny Amorsen
Cc: Stephen Hemminger, Benjamin LaHaise, Octavian Purdila, netdev
In-Reply-To: <m3r5s1bn3f.fsf@ursa.amorsen.dk>
Benny Amorsen a écrit :
> Stephen Hemminger <shemminger@vyatta.com> writes:
>
>> Then maybe network devices aren't the right layering model. At some
>> point the paradigm has to be re-examined.
>
> I'm not quite sure where this becomes a problem. We have 1185 network
> interfaces (VLAN's) on one box. Boot time is a problem, but other than
> that it works ok. If something like this would help speed up booting,
> that would be very nice.
>
It would be very nice if you tell us why booting is very long,
ie what is done and how much time it takes.
It's clear that ~1000 vlans is quite reasonable :)
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Benny Amorsen @ 2009-11-14 7:08 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Benjamin LaHaise, Octavian Purdila, Eric Dumazet, netdev
In-Reply-To: <20091113144937.23693bb4@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> Then maybe network devices aren't the right layering model. At some
> point the paradigm has to be re-examined.
I'm not quite sure where this becomes a problem. We have 1185 network
interfaces (VLAN's) on one box. Boot time is a problem, but other than
that it works ok. If something like this would help speed up booting,
that would be very nice.
/Benny
^ permalink raw reply
* linux-next: net tree build failure
From: Stephen Rothwell @ 2009-11-14 6:50 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
Hi Dave,
Today's linux-next build (alpha defconfig) failed like this:
arch/alpha/kernel/systbls.S:507: Error: .err encountered
Caused by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
Introduce recvmmsg socket syscall") which added a syscall to the alpha
syscall table but forgot to update NR_SYSCALLS in
arch/alpha/include/asm/unistd.h (it also didn't add the __NR_ constant
thee either).
I suspect that this is true for a few other architectures as well
(including sparc?).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Benjamin LaHaise @ 2009-11-14 6:24 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, opurdila, eric.dumazet, netdev
In-Reply-To: <20091113.185937.251557071.davem@davemloft.net>
On Fri, Nov 13, 2009 at 06:59:37PM -0800, David Miller wrote:
> From: Benjamin LaHaise <bcrl@lhnet.ca>
> Date: Fri, 13 Nov 2009 18:52:10 -0500
>
> > If you don't want the overhead from this kind of scaling, stick it under a
> > config option, but please don't stop other people from pushing Linux into
> > new uses which have these scaling requirements.
>
> This 'scaling requirement' only exists in environments where people
> undersubsribe their networks, right?
Depends on how you look at things. The case of lots of interfaces going
up/down can occur during normal operations. The incumbent telco in this
area has occasional flaps that reset thousands of sessions. The problem
relates to how things flop over to a different path within their network,
as they don't provide hot standby circuits for all the aggregated traffic
coming in -- a link down results in a flap of all the L2TP sessions. As
for it being underprovisioned, that doesn't really apply. The core LNS
boxes are kept from having saturated links, as that results in poor user
performance. Plus they have substantially more CPU than embedded routers.
> I'm not saying we won't put scaling into these areas, I'm just trying
> to make a point to show that this "need" only exists because people
> have purposefully created these situations where they feel the need to
> massively control their users usage in order to generate revenue.
I've finally got some of the userspace bits necessary for parallel network
device creation wired up. Will reducing the granularity of rtnl_lock() for
devices which can handle it be okay? That will get a factor of 4 to 8
improvement from current single socket hardware.
The other way I'm working around the scaling issues is to use network
namespaces. Babylon (the L2TP/PPPoE stack I'm working on) can now split
interface creation across some number of network namespaces. This keeps
the number of interfaces in a given net instance down to 5-10,000. That
really helps avoid some of the scaling issues, as we're pretty good in
that range.
The worst part of all the overhead during setup and teardown is that very
little traffic can pass while this is occurring, effectively making it an
outage, hence the desire to minimise outage situations.
-ben
^ permalink raw reply
* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: Gregory Haskins @ 2009-11-14 5:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Herbert Xu, Gregory Haskins, Michael S. Tsirkin, alacrityvm-devel,
linux-kernel, netdev
In-Reply-To: <20091113184503.13f6d447@s6510>
[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]
Stephen Hemminger wrote:
> On Fri, 13 Nov 2009 21:27:57 -0500
> Gregory Haskins <gregory.haskins@gmail.com> wrote:
>
>> Herbert Xu wrote:
>>> On Fri, Nov 13, 2009 at 08:33:35PM -0500, Gregory Haskins wrote:
>>>> Well, not with respect to the overall protocol, of course not. But with
>>>> respect to the buffer in question, it _has_ to be. Or am I missing
>>>> something?
>>> sendfile() has never guaranteed that the kernel is finished with
>>> the underlying pages when it returns.
>>>
>>> Cheers,
>> Clearly there must be _some_ mechanism to synchronize (e.g.
>> flush/barrier) though, right? Otherwise, that interface would seem to
>> be quite prone to races and would likely be unusable. So what does
>> said flush use to know when the buffer is free?
>
> No all the interfaces require a copy.
I'm sorry, but I do not think that is correct. As others have pointed
out, that would not appear to be true for at least sendfile.
> Actually, sendfile makes no guarantee about synchronization
> because the receiver of said file could be arbitrarily slow, and any attempt at locking down
> current contents of file is a denial of service exposure.
I think you are inverting the problem space. It is fully expected that
changing the "file", or the pages that represent the file before the
packet is queued would constitute the modification of the stream on the
wire.
I am more thinking about the applications of mmap+sendfile to implement
a zero-copy interface. As David mentions in another mail, it seems that
there is no sync mechanism available, so this would not appear to be a
viable use case today, unfortunately.
>
> People have tried doing copy-less send by page flipping, but the overhead of the IPI to
> invalidate the TLB exceeded the overhead of the copy. There was an Intel paper on this in
> at Linux Symposium (Ottawa) several years ago.
I think you are confusing copy-less tx with copy-less rx. You can try
to do copy-less rx with page flipping, which has the IPI/TLB thrashing
properties you mention, and I agree is problematic. We are talking
about copy-less tx here, however, and therefore no page-flipping is
involved. Rather, we are just posting SG lists of pages directly to the
NIC (assuming the nic supports HIGH_DMA, etc). You do not need to flip
the page, or invalidate the TLB (and thus IPI the other cores) to do
this to my knowledge.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH] net/can: add driver for mscan family & mpc52xx_mscan
From: David Miller @ 2009-11-14 4:51 UTC (permalink / raw)
To: w.sang; +Cc: netdev, socketcan-core, linuxppc-dev, wg, grant.likely
In-Reply-To: <1258128892-28800-1-git-send-email-w.sang@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Fri, 13 Nov 2009 17:14:52 +0100
> Taken from socketcan-svn, fixed remaining todos, cleaned up, tested with a
> phyCORE-MPC5200B-IO and a custom board.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] Phonet: convert routing table to RCU
From: David Miller @ 2009-11-14 4:51 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1258124479-1167-2-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Fri, 13 Nov 2009 17:01:19 +0200
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] Phonet: put protocols array under RCU
From: David Miller @ 2009-11-14 4:51 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1258124479-1167-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Fri, 13 Nov 2009 17:01:18 +0200
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] inetpeer: Optimize inet_getid()
From: David Miller @ 2009-11-14 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AFC62F5.60700@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 20:33:09 +0100
> While investigating for network latencies, I found inet_getid() was a
> contention point for some workloads, as inet_peer_idlock is shared
> by all inet_getid() users regardless of peers.
>
> One way to fix this is to make ip_id_count an atomic_t instead
> of __u16, and use atomic_add_return().
>
> In order to keep sizeof(struct inet_peer) = 64 on 64bit arches
> tcp_ts_stamp is also converted to __u32 instead of "unsigned long".
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: speedup inet6_dump_addr()
From: David Miller @ 2009-11-14 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger
In-Reply-To: <4AFC17A6.4040801@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 15:11:50 +0100
> When handling large number of netdevices, inet6_dump_addr()
> is very slow because it has O(N^2) complexity.
>
> Instead of scanning one single list, we can use the NETDEV_HASHENTRIES
> sub lists of the dev_index hash table, and RCU lookups.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: speedup inet_dump_ifaddr()
From: David Miller @ 2009-11-14 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <4AFC4979.7030007@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 18:44:25 +0100
> [PATCH net-next-2.6] ipv4: speedup inet_dump_ifaddr()
>
> When handling large number of netdevices, inet_dump_ifaddr()
> is very slow because it has O(N2) complexity.
>
> Instead of scanning one single list, we can use the NETDEV_HASHENTRIES
> sub lists of the dev_index hash table, and RCU lookups.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] inet: fix inet_bind_bucket_for_each
From: David Miller @ 2009-11-14 4:49 UTC (permalink / raw)
To: lgrijincu; +Cc: netdev, opurdila
In-Reply-To: <200911121707.26224.lgrijincu@ixiacom.com>
From: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
Date: Thu, 12 Nov 2009 17:07:26 +0200
> The first "node" is supposed to be the cursor used in the for_each.
>
> The second "node" is ment literally and should not be macro expanded:
> it's the name of the hlist_node field from the inet_bind_bucket.
>
> This currently works because when inet_bind_bucket_for_each is called
> it's argument is still "node".
>
> Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
Applied.
^ 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