* Re: [PATCH 1/3] USB: qmi_wwan: Make forced int 4 whitelist generic
From: David Miller @ 2012-05-20 20:59 UTC (permalink / raw)
To: ajb; +Cc: bjorn, gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-1-git-send-email-ajb@spheresystems.co.uk>
From: Andrew Bird <ajb@spheresystems.co.uk>
Date: Sun, 20 May 2012 09:28:36 +0100
> Change the forced interface 4 whitelist to use the generic shared
> binder instead of the Gobi specific one. Certain ZTE devices
> (K3520-Z & K3765-Z) don't work with the Gobi version, but function
> quite happily with the generic. This has been tested with the following
> devices:
> K3520-Z
> K3565-Z
> K3765-Z
> K4505-Z
> It hasn't been tested with the ZTE MF820D, which is the only other
> device that uses this whitelist at present. Although Bjorn doesn't
> expect any problems, any testing with that device would be appreciated.
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v6] tilegx network driver: initial support
From: David Miller @ 2012-05-20 20:55 UTC (permalink / raw)
To: cmetcalf; +Cc: bhutchings, arnd, linux-kernel, netdev
In-Reply-To: <201205201636.q4KGaoA3003845@farm-0027.internal.tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Sun, 20 May 2012 00:42:03 -0400
> +static int tile_net_tx_tso(struct sk_buff *skb, struct net_device *dev)
This function has 80 lines of local variable declarations,
that's absolutely rediculous.
A comment and an empty line interspacing many of these local
variable declarations, also rediculous, and part of why it
is 80 lines long.
This function is completely unreadable, if I have to scan
multiple pages before I get to real code, the function is
broken.
You either need to compartmentalize these variable declarations
and/or write helper functions to spread it out.
This is some of the most unpleasant code I've had to review in quite
some time. Look at other networking drivers in the tree, such as
drivers/net/ethernet/broadcom/tg3.c, and try to mimick their style and
layout. Anything in your driver that is different is likely to get
you into trouble and make your driver hard to review.
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Denys Fedoryshchenko @ 2012-05-20 19:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: e1000-devel, netdev, jesse.brandeburg, davem, Tom Herbert
In-Reply-To: <1337540825.3361.0.camel@edumazet-glaptop>
On 2012-05-20 22:07, Eric Dumazet wrote:
>
> You could try latencytop, I am not sure if some obvious things will
> popup.
For sure i did. Nothing unusual here, max 5ms latency
Cause Maximum
Percentage
[__skb_recv_datagram] 4.1 msec
45.4 %
Waiting for event (select) 3.9 msec
54.6 %
Page fault 0.7 msec
0.0 %
Waiting for a process to die 0.3 msec
0.0 %
Writing data to TTY 0.1 msec
0.0 %
I will try also to find SMI interrupts detector (if i will find
source), but i don't think it is an issue.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-20 19:07 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: e1000-devel, netdev, jesse.brandeburg, davem, Tom Herbert
In-Reply-To: <4775d023592b876909aceb152f94aa01@visp.net.lb>
On Sun, 2012-05-20 at 21:53 +0300, Denys Fedoryshchenko wrote:
> >
> My kernel config http://www.nuclearcat.com/config_stall.txt
>
> It is completely idle machine. I didn't notice any anomalies with
> interrutps to
> compare with other servers (not Sun Fire). If there is anomalies with
> interrupts
> (for example SMI), probably i should notice that even without BQL, but
> this machine
> works very well and i didn't notice any latency without BQL.
You could try latencytop, I am not sure if some obvious things will
popup.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Denys Fedoryshchenko @ 2012-05-20 18:53 UTC (permalink / raw)
To: Tom Herbert; +Cc: e1000-devel, netdev, jesse.brandeburg, davem
In-Reply-To: <CA+mtBx_sF5GCMRpLQuTruZ=xpFTFpd5z8SZJaG_dBqf4oCXpwg@mail.gmail.com>
>
> And I didn't see the stalls. This was on an Intel machine. The limit
> was stable, went up to around 28K when opened large file and tended
> to
> stay between 15-28K.
>
> The describe problem seems to have characteristics that transmit
> interrupts are not at all periodic, and it would seem that some are
> taking hundreds of milliseconds to pop. I don't see anything that
> would cause that in the NIC, is it possible there is some activity on
> the machines periodically and often holding down interrupts for long
> periods of time. Are there any peculiarities on Sun Fire in
> interrupt
> handling?
>
> Can you also provide an 'ethtool -c eth0'
>
> Thanks,
> Tom
>
Technically i can install there fresh gentoo with latest vanilla kernel
and provide remote access.
But it will take some time. I will try now to play with IRQ pinning,
but not sure i will reach anything.
My kernel config http://www.nuclearcat.com/config_stall.txt
It is completely idle machine. I didn't notice any anomalies with
interrutps to
compare with other servers (not Sun Fire). If there is anomalies with
interrupts
(for example SMI), probably i should notice that even without BQL, but
this machine
works very well and i didn't notice any latency without BQL.
centaur ~ # pidstat 1
Linux 3.4.0-rc7-centaur (centaur) 05/20/12 _x86_64_
(8 CPU)
21:41:25 PID %usr %system %guest %CPU CPU Command
21:41:26 PID %usr %system %guest %CPU CPU Command
21:41:27 2617 0.00 1.00 0.00 1.00 2 pidstat
21:41:27 PID %usr %system %guest %CPU CPU Command
21:41:28 PID %usr %system %guest %CPU CPU Command
21:41:29 PID %usr %system %guest %CPU CPU Command
21:41:30 2617 0.00 1.00 0.00 1.00 2 pidstat
From powertop:
Wakeups-from-idle per second : 7.5 interval: 10.0s
ethtool -c eth0, sure i can provide, it is default values:
centaur ~ # ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: off TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
rx-usecs: 3
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0
tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
>
>
>
> On Fri, May 18, 2012 at 7:40 PM, Denys Fedoryshchenko
> <denys@visp.net.lb> wrote:
>> On 2012-05-19 05:07, Tom Herbert wrote:
>>>
>>> 3) Have you tried a different interrupt mode?
>>
>>
>> Now tested:
>> e1000e.TxIntDelay=0,0,0,0
>> [ 4.930570] e1000e 0000:04:00.0: (unregistered net_device):
>> Transmit
>> Interrupt Delay set to 0
>> [ 4.930573] e1000e 0000:04:00.0: (unregistered net_device):
>> Interrupt
>> Throttling Rate (ints/sec) set to dynamic conservative mode
>> Problem still occur.
>>
>> e1000e.TxIntDelay=0,0,0,0 e1000e.InterruptThrottleRate=0,0,0,0
>> [ 4.971476] e1000e 0000:04:00.0: (unregistered net_device):
>> Transmit
>> Interrupt Delay set to 0
>> [ 4.971478] e1000e 0000:04:00.0: (unregistered net_device):
>> Interrupt
>> Throttling Rate (ints/sec) turned off
>> Problem also occur.
>>
>> Probably it is a case of this specific machine, this problem is
>> happened on
>> same hardware (Sun Fire X4150).
>> The only "exotic" thing here is set of cards:
>>
>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>> Ethernet
>> Controller (Copper) (rev 01)
>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>> Ethernet
>> Controller (Copper) (rev 01)
>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>> Ethernet
>> Controller (rev 06)
>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>> Ethernet
>> Controller (rev 06)
>>
>> I'm using first card.
>>
>>
>>>
>>> Per #3, I am wondering if dynamic conservative mode interrupt
>>> throttling is not producing interrupts deterministically for BQL.
>>> I'll try to reproduce the problem in this mode.
>>>
>>>> I can make a patch that will make minimum BQL value not less than
>>>> MTU +
>>>> overhead, is it ok like this?
>>>> Probably it will solve issue, but it is more workaround and safety
>>>> fuse,
>>>> than a solution.
>>>>
>>> That would just be a bandaid and could just make this a latent
>>> issue
>>> for the future.
>>>
>>> Tom
>>>
>>>>
>>>> On 2012-05-17 19:54, Denys Fedoryshchenko wrote:
>>>>>
>>>>>
>>>>> Also i notice, limit constantly changing over time (even i am not
>>>>> touching it).
>>>>>
>>>>> centaur ~ # grep ""
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:0
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>>
>>>>>
>>>>>
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>>> centaur ~ # grep ""
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:4542
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>>
>>>>>
>>>>>
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>>>
>>>>> Is it supposed to be like this?
>>>>>
>>>>> On 2012-05-17 16:42, Denys Fedoryshchenko wrote:
>>>>>>
>>>>>>
>>>>>> Found commit that cause problem:
>>>>>>
>>>>>> author Tom Herbert <therbert@google.com>
>>>>>> Mon, 28 Nov 2011 16:33:16 +0000 (16:33 +0000)
>>>>>> committer David S. Miller <davem@davemloft.net>
>>>>>> Tue, 29 Nov 2011 17:46:19 +0000 (12:46 -0500)
>>>>>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>>>>>> tree d6670a4f94b2b9dedacc38edb6f0e1306b889f6b tree |
>>>>>> snapshot
>>>>>> parent 114cf5802165ee93e3ab461c9c505cd94a08b800 commit |
>>>>>> diff
>>>>>> e1000e: Support for byte queue limits
>>>>>>
>>>>>> Changes to e1000e to use byte queue limits.
>>>>>>
>>>>>> Signed-off-by: Tom Herbert <therbert@google.com>
>>>>>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>>>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>>>
>>>>>> If i reverse it, problem disappearing.
>>>>>>
>>>>>> How i reproduce it:
>>>>>> In two consoles do "fast" ping to nearby host
>>>>>> ping 194.146.XXX.XXX -s1472 -i0.0001
>>>>>> ping 194.146.XXX.XXX -s1472 -i0.1
>>>>>>
>>>>>> For third open ssh to host with "problem", open mcedit, and just
>>>>>> scroll down large text file.
>>>>>> After few seconds some "stalls" will occur, and in ping history
>>>>>> i can
>>>>>> see:
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1797 ttl=64 time=0.161
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1798 ttl=64 time=0.198
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1799 ttl=64 time=0.340
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1800 ttl=64 time=0.381
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1801 ttl=64 time=914 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1802 ttl=64 time=804 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1803 ttl=64 time=704 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1804 ttl=64 time=594 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1805 ttl=64 time=0.287
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1806 ttl=64 time=0.226
>>>>>> ms
>>>>>>
>>>>>>
>>>>>> If i apply small patch - problem will disappear. Sure it is not
>>>>>> a
>>>>>> solution, but
>>>>>> let me know how i can help to debug problem more.
>>>>>>
>>>>>> --- netdev.c 2012-05-12 20:08:37.000000000 +0300
>>>>>> +++ netdev.c.patched 2012-05-17 16:32:28.895760472 +0300
>>>>>> @@ -1135,7 +1135,7 @@
>>>>>>
>>>>>> tx_ring->next_to_clean = i;
>>>>>>
>>>>>> - netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>>> +// netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>>>
>>>>>> #define TX_WAKE_THRESHOLD 32
>>>>>> if (count && netif_carrier_ok(netdev) &&
>>>>>> @@ -2263,7 +2263,7 @@
>>>>>> e1000_put_txbuf(adapter, buffer_info);
>>>>>> }
>>>>>>
>>>>>> - netdev_reset_queue(adapter->netdev);
>>>>>> +// netdev_reset_queue(adapter->netdev);
>>>>>> size = sizeof(struct e1000_buffer) * tx_ring->count;
>>>>>> memset(tx_ring->buffer_info, 0, size);
>>>>>>
>>>>>> @@ -5056,7 +5056,7 @@
>>>>>> /* if count is 0 then mapping error has occurred */
>>>>>> count = e1000_tx_map(adapter, skb, first, max_per_txd,
>>>>>> nr_frags, mss);
>>>>>> if (count) {
>>>>>> - netdev_sent_queue(netdev, skb->len);
>>>>>> +// netdev_sent_queue(netdev, skb->len);
>>>>>> e1000_tx_queue(adapter, tx_flags, count);
>>>>>> /* Make sure there is space in the ring for the
>>>>>> next
>>>>>> send.
>>>>>> */
>>>>>> e1000_maybe_stop_tx(netdev, MAX_SKB_FRAGS + 2);
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2012-05-15 17:15, Denys Fedoryshchenko wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have two identical servers, Sun Fire X4150, both has
>>>>>>> different
>>>>>>> flavors of Linux, x86_64 and i386.
>>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> I am using now interface:
>>>>>>> #ethtool -i eth0
>>>>>>> driver: e1000e
>>>>>>> version: 1.9.5-k
>>>>>>> firmware-version: 2.1-11
>>>>>>> bus-info: 0000:04:00.0
>>>>>>> There is 2 CPU , Intel(R) Xeon(R) CPU E5440 @
>>>>>>> 2.83GHz .
>>>>>>>
>>>>>>> i386 was acting as NAT and shaper, and as soon as i removed
>>>>>>> shaper
>>>>>>> from it, i started to experience strange lockups, e.g. traffic
>>>>>>> is
>>>>>>> normal for 5-30 seconds, then short lockup for 500-3000ms
>>>>>>> (usually
>>>>>>> around 1000ms) with dropped packets counter increasing. I was
>>>>>>> suspecting it is due load, but it seems was wrong.
>>>>>>> Recently, on another server, x86_64 i am using as development,
>>>>>>> i
>>>>>>> upgrade kernel (it was old, from 2.6 series) and on completely
>>>>>>> idle
>>>>>>> machine started to experience same latency spikes, while i am
>>>>>>> just
>>>>>>> running mc and for example typing in text editor - i notice
>>>>>>> "stalls".
>>>>>>> After i investigate it a little more, i notice also small
>>>>>>> amount of
>>>>>>> drops on interface. No tcpdump running. Also this machine is
>>>>>>> idle, and
>>>>>>> the only traffic there - some small broadcasts from network, my
>>>>>>> ssh,
>>>>>>> and ping.
>>>>>>>
>>>>>>> Dropped packets in ifconfig
>>>>>>> RX packets:3752868 errors:0 dropped:5350 overruns:0
>>>>>>> frame:0
>>>>>>> Counter is increasing sometimes, when this stall happening.
>>>>>>>
>>>>>>> ethtool -S is clean, there is no dropped packets.
>>>>>>>
>>>>>>> I did tried to check load (mpstat and perf), there is nothing
>>>>>>> suspicious, latencytop also doesn't show anything suspicious.
>>>>>>> dropwatch report a lot of drops, but mostly because there is
>>>>>>> some
>>>>>>> broadcasts and etc. tcpdump at the moment of such drops doesn't
>>>>>>> show
>>>>>>> anything suspicious.
>>>>>>> Changed qdisc from default fifo_fast to bfifo, without any
>>>>>>> result.
>>>>>>> Tried: ethtool -K eth0 tso off gso off gro off sg off , no
>>>>>>> result
>>>>>>> Problem occured at 3.3.6 - 3.4.0-rc7, most probably 3.3.0 also,
>>>>>>> but i
>>>>>>> don't remember for sure. I thik on some kernels like 3.1
>>>>>>> probably it
>>>>>>> doesn't occur, i will check it soon, because it is not always
>>>>>>> reliable
>>>>>>> to reproduce it. All tests i did on 3.4.0-rc7.
>>>>>>>
>>>>>>> I did run also in background tcpdump, additionally iptables
>>>>>>> with
>>>>>>> timestamps, and at time when stall occured, seems i am still
>>>>>>> receiving
>>>>>>> packets properly, also on iperf udp (from some host to this
>>>>>>> SunFire)
>>>>>>> at this moments no packets missing. But i am sure RX interface
>>>>>>> errors
>>>>>>> are increasing.
>>>>>>> If i do iperf from SunFire to test host - there is packetloss
>>>>>>> at
>>>>>>> moments when stall occured.
>>>>>>>
>>>>>>> I suspect that by some reason network card stop to transmit,
>>>>>>> but
>>>>>>> unable to pinpoint issue. All other hosts in this network are
>>>>>>> fine and
>>>>>>> don't have such problems.
>>>>>>> Can you help me with that please? Maybe i can provide more
>>>>>>> debug
>>>>>>> information, compile with patches and etc. Also i will try to
>>>>>>> fallback
>>>>>>> to 3.1 and 3.0 kernels.
>>>>>>>
>>>>>>> Here it is how it occurs and i am reproducing it:
>>>>>>> I'm just opening file, and start to scroll it in mc, then in
>>>>>>> another
>>>>>>> console i run ping
>>>>>>> [1337089061.844167] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=162
>>>>>>> ttl=64 time=0.485 ms
>>>>>>> [1337089061.944138] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=163
>>>>>>> ttl=64 time=0.470 ms
>>>>>>> [1337089062.467759] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=164
>>>>>>> ttl=64 time=424 ms
>>>>>>> [1337089062.467899] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=165
>>>>>>> ttl=64 time=324 ms
>>>>>>> [1337089062.468058] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=166
>>>>>>> ttl=64 time=214 ms
>>>>>>> [1337089062.468161] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=167
>>>>>>> ttl=64 time=104 ms
>>>>>>> [1337089062.468958] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=168
>>>>>>> ttl=64 time=1.15 ms
>>>>>>> [1337089062.568604] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=169
>>>>>>> ttl=64 time=0.477 ms
>>>>>>> [1337089062.668909] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=170
>>>>>>> ttl=64 time=0.667 ms
>>>>>>>
>>>>>>> Remote host tcpdump:
>>>>>>> 1337089061.934737 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 163, length 1480
>>>>>>> 1337089062.458360 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 164, length 1480
>>>>>>> 1337089062.458380 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 164, length 1480
>>>>>>> 1337089062.458481 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 165, length 1480
>>>>>>> 1337089062.458502 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 165, length 1480
>>>>>>> 1337089062.458606 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 166, length 1480
>>>>>>> 1337089062.458623 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 166, length 1480
>>>>>>> 1337089062.458729 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 167, length 1480
>>>>>>> 1337089062.458745 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 167, length 1480
>>>>>>> 1337089062.459537 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 168, length 1480
>>>>>>> 1337089062.459545 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 168, length 1480
>>>>>>>
>>>>>>> Local host(SunFire) tcpdump:
>>>>>>> 1337089061.844140 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 162, length 1480
>>>>>>> 1337089061.943661 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 163, length 1480
>>>>>>> 1337089061.944124 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 163, length 1480
>>>>>>> 1337089062.465622 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 164, length 1480
>>>>>>> 1337089062.465630 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 165, length 1480
>>>>>>> 1337089062.465632 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 166, length 1480
>>>>>>> 1337089062.465634 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 167, length 1480
>>>>>>> 1337089062.467730 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 164, length 1480
>>>>>>> 1337089062.467785 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 168, length 1480
>>>>>>> 1337089062.467884 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 165, length 1480
>>>>>>> 1337089062.468035 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 166, length 1480
>>>>>>> 1337089062.468129 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 167, length 1480
>>>>>>> 1337089062.468928 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 168, length 1480
>>>>>>> 1337089062.568112 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 169, length 1480
>>>>>>> 1337089062.568578 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 169, length 1480
>>>>>>>
>>>>>>> lspci -t
>>>>>>> centaur src # lspci -t
>>>>>>> -[0000:00]-+-00.0
>>>>>>> +-02.0-[01-05]--+-00.0-[02-04]--+-00.0-[03]--
>>>>>>> | | \-02.0-[04]--+-00.0
>>>>>>> | | \-00.1
>>>>>>> | \-00.3-[05]--
>>>>>>> +-03.0-[06]--
>>>>>>> +-04.0-[07]----00.0
>>>>>>> +-05.0-[08]--
>>>>>>> +-06.0-[09]--
>>>>>>> +-07.0-[0a]--
>>>>>>> +-08.0
>>>>>>> +-10.0
>>>>>>> +-10.1
>>>>>>> +-10.2
>>>>>>> +-11.0
>>>>>>> +-13.0
>>>>>>> +-15.0
>>>>>>> +-16.0
>>>>>>> +-1c.0-[0b]--+-00.0
>>>>>>> | \-00.1
>>>>>>> +-1d.0
>>>>>>> +-1d.1
>>>>>>> +-1d.2
>>>>>>> +-1d.3
>>>>>>> +-1d.7
>>>>>>> +-1e.0-[0c]----05.0
>>>>>>> +-1f.0
>>>>>>> +-1f.1
>>>>>>> +-1f.2
>>>>>>> \-1f.3
>>>>>>> lspci
>>>>>>> 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory
>>>>>>> Controller Hub (rev b1)
>>>>>>> 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 2 (rev b1)
>>>>>>> 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 3 (rev b1)
>>>>>>> 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x8 Port 4-5 (rev b1)
>>>>>>> 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 5 (rev b1)
>>>>>>> 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x8 Port 6-7 (rev b1)
>>>>>>> 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 7 (rev b1)
>>>>>>> 00:08.0 System peripheral: Intel Corporation 5000 Series
>>>>>>> Chipset DMA
>>>>>>> Engine (rev b1)
>>>>>>> 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>>> Registers (rev b1)
>>>>>>> 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>>> Registers (rev b1)
>>>>>>> 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>>> Registers (rev b1)
>>>>>>> 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset
>>>>>>> Reserved
>>>>>>> Registers (rev b1)
>>>>>>> 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset
>>>>>>> Reserved
>>>>>>> Registers (rev b1)
>>>>>>> 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>>> Registers (rev b1)
>>>>>>> 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>>> Registers (rev b1)
>>>>>>> 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset
>>>>>>> PCI Express Root Port 1 (rev 09)
>>>>>>> 00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #1 (rev 09)
>>>>>>> 00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #2 (rev 09)
>>>>>>> 00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #3 (rev 09)
>>>>>>> 00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #4 (rev 09)
>>>>>>> 00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset EHCI USB2 Controller (rev 09)
>>>>>>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
>>>>>>> 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset
>>>>>>> LPC Interface Controller (rev 09)
>>>>>>> 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE
>>>>>>> Controller (rev 09)
>>>>>>> 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA
>>>>>>> AHCI
>>>>>>> Controller (rev 09)
>>>>>>> 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset
>>>>>>> SMBus
>>>>>>> Controller (rev 09)
>>>>>>> 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express
>>>>>>> Upstream Port (rev 01)
>>>>>>> 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express to
>>>>>>> PCI-X Bridge (rev 01)
>>>>>>> 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express
>>>>>>> Downstream Port E1 (rev 01)
>>>>>>> 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express
>>>>>>> Downstream Port E3 (rev 01)
>>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 07:00.0 RAID bus controller: Adaptec AAC-RAID (rev 09)
>>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> 0c:05.0 VGA compatible controller: ASPEED Technology, Inc.
>>>>>>> ASPEED
>>>>>>> Graphics Family
>>>>>>>
>>>>>>>
>>>>>>> dmesg:
>>>>>>> [ 4.936885] e1000: Intel(R) PRO/1000 Network Driver -
>>>>>>> version
>>>>>>> 7.3.21-k8-NAPI
>>>>>>> [ 4.936887] e1000: Copyright (c) 1999-2006 Intel
>>>>>>> Corporation.
>>>>>>> [ 4.936966] e1000e: Intel(R) PRO/1000 Network Driver -
>>>>>>> 1.9.5-k
>>>>>>> [ 4.936967] e1000e: Copyright(c) 1999 - 2012 Intel
>>>>>>> Corporation.
>>>>>>> [ 4.938529] e1000e 0000:04:00.0: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 4.939598] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>>> [ 4.992246] e1000e 0000:04:00.0: eth0: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:f8
>>>>>>> [ 4.992657] e1000e 0000:04:00.0: eth0: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 4.992964] e1000e 0000:04:00.0: eth0: MAC: 5, PHY: 5, PBA
>>>>>>> No:
>>>>>>> FFFFFF-0FF
>>>>>>> [ 4.994745] e1000e 0000:04:00.1: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 4.996233] e1000e 0000:04:00.1: irq 66 for MSI/MSI-X
>>>>>>> [ 5.050901] e1000e 0000:04:00.1: eth1: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:f9
>>>>>>> [ 5.051317] e1000e 0000:04:00.1: eth1: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 5.051623] e1000e 0000:04:00.1: eth1: MAC: 5, PHY: 5, PBA
>>>>>>> No:
>>>>>>> FFFFFF-0FF
>>>>>>> [ 5.051857] e1000e 0000:0b:00.0: Disabling ASPM L1
>>>>>>> [ 5.052168] e1000e 0000:0b:00.0: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 5.052611] e1000e 0000:0b:00.0: irq 67 for MSI/MSI-X
>>>>>>> [ 5.223454] e1000e 0000:0b:00.0: eth2: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:fa
>>>>>>> [ 5.223864] e1000e 0000:0b:00.0: eth2: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 5.224178] e1000e 0000:0b:00.0: eth2: MAC: 0, PHY: 4, PBA
>>>>>>> No:
>>>>>>> C83246-002
>>>>>>> [ 5.224412] e1000e 0000:0b:00.1: Disabling ASPM L1
>>>>>>> [ 5.224709] e1000e 0000:0b:00.1: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 5.225168] e1000e 0000:0b:00.1: irq 68 for MSI/MSI-X
>>>>>>> [ 5.397603] e1000e 0000:0b:00.1: eth3: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:fb
>>>>>>> [ 5.398021] e1000e 0000:0b:00.1: eth3: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 5.398336] e1000e 0000:0b:00.1: eth3: MAC: 0, PHY: 4, PBA
>>>>>>> No:
>>>>>>> C83246-002
>>>>>>> [ 13.859817] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>>> [ 13.962309] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>>> [ 17.150392] e1000e: eth0 NIC Link is Up 1000 Mbps Full
>>>>>>> Duplex,
>>>>>>> Flow Control: None
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>> netdev" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at
>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Network engineer
>>>>>> Denys Fedoryshchenko
>>>>>>
>>>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>>>> Beirut, Lebanon
>>>>>> Tel: +961 1 247373
>>>>>> E-Mail: denys@visp.net.lb
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at
>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Network engineer
>>>>> Denys Fedoryshchenko
>>>>>
>>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>>> Beirut, Lebanon
>>>>> Tel: +961 1 247373
>>>>> E-Mail: denys@visp.net.lb
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev"
>>>>> in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at
>>>>> http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> ---
>>>> Network engineer
>>>> Denys Fedoryshchenko
>>>>
>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>> Beirut, Lebanon
>>>> Tel: +961 1 247373
>>>> E-Mail: denys@visp.net.lb
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>> ---
>> Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-20 18:13 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: e1000-devel, netdev, jesse.brandeburg, davem, therbert
In-Reply-To: <d3a88d6c741394a48aee6179d58e4edf@visp.net.lb>
On Fri, 2012-05-18 at 17:04 +0300, Denys Fedoryshchenko wrote:
> It seems logic in BQL has serious issues. The most bad thing, if
> and it is empty. So in result, instead of eliminating latency, it is
> adding it.
There is maybe a misunderstanding here. BQL by itself only reduce amount
of buffering in TX ring. Now there's still the Qdisc layer.
On my laptop (e1000e NIC), and default pfifo_fast I can immediately see
the difference in ping results if I launch a single netperf TCP_STREAM
in another window :
1480 bytes from 172.30.42.1: icmp_seq=5047 ttl=64 time=0.185 ms
1480 bytes from 172.30.42.1: icmp_seq=5048 ttl=64 time=0.198 ms
1480 bytes from 172.30.42.1: icmp_seq=5049 ttl=64 time=0.255 ms
1480 bytes from 172.30.42.1: icmp_seq=5050 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=5051 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=5052 ttl=64 time=0.226 ms
1480 bytes from 172.30.42.1: icmp_seq=5053 ttl=64 time=0.186 ms
1480 bytes from 172.30.42.1: icmp_seq=5054 ttl=64 time=0.190 ms
1480 bytes from 172.30.42.1: icmp_seq=5055 ttl=64 time=0.223 ms
1480 bytes from 172.30.42.1: icmp_seq=5056 ttl=64 time=0.178 ms
1480 bytes from 172.30.42.1: icmp_seq=5057 ttl=64 time=0.191 ms
1480 bytes from 172.30.42.1: icmp_seq=5058 ttl=64 time=0.229 ms
1480 bytes from 172.30.42.1: icmp_seq=5059 ttl=64 time=0.229 ms
1480 bytes from 172.30.42.1: icmp_seq=5060 ttl=64 time=0.213 ms
1480 bytes from 172.30.42.1: icmp_seq=5061 ttl=64 time=0.187 ms
1480 bytes from 172.30.42.1: icmp_seq=5062 ttl=64 time=0.944 ms
1480 bytes from 172.30.42.1: icmp_seq=5063 ttl=64 time=4.67 ms
1480 bytes from 172.30.42.1: icmp_seq=5064 ttl=64 time=8.55 ms
1480 bytes from 172.30.42.1: icmp_seq=5065 ttl=64 time=12.8 ms
1480 bytes from 172.30.42.1: icmp_seq=5066 ttl=64 time=16.9 ms
1480 bytes from 172.30.42.1: icmp_seq=5067 ttl=64 time=20.5 ms
1480 bytes from 172.30.42.1: icmp_seq=5068 ttl=64 time=24.3 ms
1480 bytes from 172.30.42.1: icmp_seq=5069 ttl=64 time=27.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5070 ttl=64 time=26.8 ms
1480 bytes from 172.30.42.1: icmp_seq=5071 ttl=64 time=26.7 ms
1480 bytes from 172.30.42.1: icmp_seq=5072 ttl=64 time=26.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5073 ttl=64 time=27.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5074 ttl=64 time=25.6 ms
1480 bytes from 172.30.42.1: icmp_seq=5075 ttl=64 time=26.7 ms
1480 bytes from 172.30.42.1: icmp_seq=5076 ttl=64 time=26.9 ms
1480 bytes from 172.30.42.1: icmp_seq=5077 ttl=64 time=25.0 ms
Now if I replace pfifo_fast by fq_codel : (still TSO and GSO are on)
1480 bytes from 172.30.42.1: icmp_seq=37 ttl=64 time=0.197 ms
1480 bytes from 172.30.42.1: icmp_seq=38 ttl=64 time=0.283 ms
1480 bytes from 172.30.42.1: icmp_seq=39 ttl=64 time=0.183 ms
1480 bytes from 172.30.42.1: icmp_seq=40 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=41 ttl=64 time=0.207 ms
1480 bytes from 172.30.42.1: icmp_seq=42 ttl=64 time=0.202 ms
1480 bytes from 172.30.42.1: icmp_seq=43 ttl=64 time=0.244 ms
1480 bytes from 172.30.42.1: icmp_seq=44 ttl=64 time=0.200 ms
1480 bytes from 172.30.42.1: icmp_seq=45 ttl=64 time=0.212 ms
1480 bytes from 172.30.42.1: icmp_seq=46 ttl=64 time=0.215 ms
1480 bytes from 172.30.42.1: icmp_seq=47 ttl=64 time=0.178 ms
1480 bytes from 172.30.42.1: icmp_seq=48 ttl=64 time=0.215 ms
1480 bytes from 172.30.42.1: icmp_seq=49 ttl=64 time=0.238 ms
1480 bytes from 172.30.42.1: icmp_seq=50 ttl=64 time=0.210 ms
1480 bytes from 172.30.42.1: icmp_seq=51 ttl=64 time=0.974 ms
1480 bytes from 172.30.42.1: icmp_seq=52 ttl=64 time=1.93 ms
1480 bytes from 172.30.42.1: icmp_seq=53 ttl=64 time=1.71 ms
1480 bytes from 172.30.42.1: icmp_seq=54 ttl=64 time=3.07 ms
1480 bytes from 172.30.42.1: icmp_seq=55 ttl=64 time=3.47 ms
1480 bytes from 172.30.42.1: icmp_seq=56 ttl=64 time=2.53 ms
1480 bytes from 172.30.42.1: icmp_seq=57 ttl=64 time=3.24 ms
1480 bytes from 172.30.42.1: icmp_seq=58 ttl=64 time=3.11 ms
1480 bytes from 172.30.42.1: icmp_seq=59 ttl=64 time=3.03 ms
1480 bytes from 172.30.42.1: icmp_seq=60 ttl=64 time=2.96 ms
1480 bytes from 172.30.42.1: icmp_seq=61 ttl=64 time=2.90 ms
1480 bytes from 172.30.42.1: icmp_seq=62 ttl=64 time=2.97 ms
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Tom Herbert @ 2012-05-20 17:40 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: netdev, e1000-devel, jeffrey.t.kirsher, jesse.brandeburg,
eric.dumazet, davem
In-Reply-To: <79d6b56fdf5f4be4656079568d5a7445@visp.net.lb>
Tried to reproduce:
May 20 10:08:30 test kernel: [ 6.168240] e1000e 0000:06:00.0:
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to
dynamic conservative mode
May 20 10:08:30 test kernel: [ 6.221591] e1000e 0000:06:00.1:
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to
dynamic conservative mode
06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
Following above instructions to repro gives:
1480 bytes from test2 (192.168.2.49): icmp_req=5875 ttl=64 time=0.358 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5876 ttl=64 time=0.330 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5877 ttl=64 time=0.337 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5878 ttl=64 time=0.375 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5879 ttl=64 time=0.359 ms
1480 bytes from lpb49.prod.google.com (192.168.2.49): icmp_req=5880
ttl=64 time=0.380 ms
And I didn't see the stalls. This was on an Intel machine. The limit
was stable, went up to around 28K when opened large file and tended to
stay between 15-28K.
The describe problem seems to have characteristics that transmit
interrupts are not at all periodic, and it would seem that some are
taking hundreds of milliseconds to pop. I don't see anything that
would cause that in the NIC, is it possible there is some activity on
the machines periodically and often holding down interrupts for long
periods of time. Are there any peculiarities on Sun Fire in interrupt
handling?
Can you also provide an 'ethtool -c eth0'
Thanks,
Tom
On Fri, May 18, 2012 at 7:40 PM, Denys Fedoryshchenko <denys@visp.net.lb> wrote:
> On 2012-05-19 05:07, Tom Herbert wrote:
>>
>> 3) Have you tried a different interrupt mode?
>
>
> Now tested:
> e1000e.TxIntDelay=0,0,0,0
> [ 4.930570] e1000e 0000:04:00.0: (unregistered net_device): Transmit
> Interrupt Delay set to 0
> [ 4.930573] e1000e 0000:04:00.0: (unregistered net_device): Interrupt
> Throttling Rate (ints/sec) set to dynamic conservative mode
> Problem still occur.
>
> e1000e.TxIntDelay=0,0,0,0 e1000e.InterruptThrottleRate=0,0,0,0
> [ 4.971476] e1000e 0000:04:00.0: (unregistered net_device): Transmit
> Interrupt Delay set to 0
> [ 4.971478] e1000e 0000:04:00.0: (unregistered net_device): Interrupt
> Throttling Rate (ints/sec) turned off
> Problem also occur.
>
> Probably it is a case of this specific machine, this problem is happened on
> same hardware (Sun Fire X4150).
> The only "exotic" thing here is set of cards:
>
> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet
> Controller (Copper) (rev 01)
> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet
> Controller (Copper) (rev 01)
> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
> Controller (rev 06)
> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
> Controller (rev 06)
>
> I'm using first card.
>
>
>>
>> Per #3, I am wondering if dynamic conservative mode interrupt
>> throttling is not producing interrupts deterministically for BQL.
>> I'll try to reproduce the problem in this mode.
>>
>>> I can make a patch that will make minimum BQL value not less than MTU +
>>> overhead, is it ok like this?
>>> Probably it will solve issue, but it is more workaround and safety fuse,
>>> than a solution.
>>>
>> That would just be a bandaid and could just make this a latent issue
>> for the future.
>>
>> Tom
>>
>>>
>>> On 2012-05-17 19:54, Denys Fedoryshchenko wrote:
>>>>
>>>>
>>>> Also i notice, limit constantly changing over time (even i am not
>>>> touching it).
>>>>
>>>> centaur ~ # grep "" /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:0
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>
>>>>
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>> centaur ~ # grep "" /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:4542
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>
>>>>
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>>
>>>> Is it supposed to be like this?
>>>>
>>>> On 2012-05-17 16:42, Denys Fedoryshchenko wrote:
>>>>>
>>>>>
>>>>> Found commit that cause problem:
>>>>>
>>>>> author Tom Herbert <therbert@google.com>
>>>>> Mon, 28 Nov 2011 16:33:16 +0000 (16:33 +0000)
>>>>> committer David S. Miller <davem@davemloft.net>
>>>>> Tue, 29 Nov 2011 17:46:19 +0000 (12:46 -0500)
>>>>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>>>>> tree d6670a4f94b2b9dedacc38edb6f0e1306b889f6b tree | snapshot
>>>>> parent 114cf5802165ee93e3ab461c9c505cd94a08b800 commit | diff
>>>>> e1000e: Support for byte queue limits
>>>>>
>>>>> Changes to e1000e to use byte queue limits.
>>>>>
>>>>> Signed-off-by: Tom Herbert <therbert@google.com>
>>>>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>>
>>>>> If i reverse it, problem disappearing.
>>>>>
>>>>> How i reproduce it:
>>>>> In two consoles do "fast" ping to nearby host
>>>>> ping 194.146.XXX.XXX -s1472 -i0.0001
>>>>> ping 194.146.XXX.XXX -s1472 -i0.1
>>>>>
>>>>> For third open ssh to host with "problem", open mcedit, and just
>>>>> scroll down large text file.
>>>>> After few seconds some "stalls" will occur, and in ping history i can
>>>>> see:
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1797 ttl=64 time=0.161 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1798 ttl=64 time=0.198 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1799 ttl=64 time=0.340 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1800 ttl=64 time=0.381 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1801 ttl=64 time=914 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1802 ttl=64 time=804 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1803 ttl=64 time=704 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1804 ttl=64 time=594 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1805 ttl=64 time=0.287 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1806 ttl=64 time=0.226 ms
>>>>>
>>>>>
>>>>> If i apply small patch - problem will disappear. Sure it is not a
>>>>> solution, but
>>>>> let me know how i can help to debug problem more.
>>>>>
>>>>> --- netdev.c 2012-05-12 20:08:37.000000000 +0300
>>>>> +++ netdev.c.patched 2012-05-17 16:32:28.895760472 +0300
>>>>> @@ -1135,7 +1135,7 @@
>>>>>
>>>>> tx_ring->next_to_clean = i;
>>>>>
>>>>> - netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>> +// netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>>
>>>>> #define TX_WAKE_THRESHOLD 32
>>>>> if (count && netif_carrier_ok(netdev) &&
>>>>> @@ -2263,7 +2263,7 @@
>>>>> e1000_put_txbuf(adapter, buffer_info);
>>>>> }
>>>>>
>>>>> - netdev_reset_queue(adapter->netdev);
>>>>> +// netdev_reset_queue(adapter->netdev);
>>>>> size = sizeof(struct e1000_buffer) * tx_ring->count;
>>>>> memset(tx_ring->buffer_info, 0, size);
>>>>>
>>>>> @@ -5056,7 +5056,7 @@
>>>>> /* if count is 0 then mapping error has occurred */
>>>>> count = e1000_tx_map(adapter, skb, first, max_per_txd,
>>>>> nr_frags, mss);
>>>>> if (count) {
>>>>> - netdev_sent_queue(netdev, skb->len);
>>>>> +// netdev_sent_queue(netdev, skb->len);
>>>>> e1000_tx_queue(adapter, tx_flags, count);
>>>>> /* Make sure there is space in the ring for the next
>>>>> send.
>>>>> */
>>>>> e1000_maybe_stop_tx(netdev, MAX_SKB_FRAGS + 2);
>>>>>
>>>>>
>>>>>
>>>>> On 2012-05-15 17:15, Denys Fedoryshchenko wrote:
>>>>>>
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I have two identical servers, Sun Fire X4150, both has different
>>>>>> flavors of Linux, x86_64 and i386.
>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> I am using now interface:
>>>>>> #ethtool -i eth0
>>>>>> driver: e1000e
>>>>>> version: 1.9.5-k
>>>>>> firmware-version: 2.1-11
>>>>>> bus-info: 0000:04:00.0
>>>>>> There is 2 CPU , Intel(R) Xeon(R) CPU E5440 @ 2.83GHz .
>>>>>>
>>>>>> i386 was acting as NAT and shaper, and as soon as i removed shaper
>>>>>> from it, i started to experience strange lockups, e.g. traffic is
>>>>>> normal for 5-30 seconds, then short lockup for 500-3000ms (usually
>>>>>> around 1000ms) with dropped packets counter increasing. I was
>>>>>> suspecting it is due load, but it seems was wrong.
>>>>>> Recently, on another server, x86_64 i am using as development, i
>>>>>> upgrade kernel (it was old, from 2.6 series) and on completely idle
>>>>>> machine started to experience same latency spikes, while i am just
>>>>>> running mc and for example typing in text editor - i notice "stalls".
>>>>>> After i investigate it a little more, i notice also small amount of
>>>>>> drops on interface. No tcpdump running. Also this machine is idle, and
>>>>>> the only traffic there - some small broadcasts from network, my ssh,
>>>>>> and ping.
>>>>>>
>>>>>> Dropped packets in ifconfig
>>>>>> RX packets:3752868 errors:0 dropped:5350 overruns:0 frame:0
>>>>>> Counter is increasing sometimes, when this stall happening.
>>>>>>
>>>>>> ethtool -S is clean, there is no dropped packets.
>>>>>>
>>>>>> I did tried to check load (mpstat and perf), there is nothing
>>>>>> suspicious, latencytop also doesn't show anything suspicious.
>>>>>> dropwatch report a lot of drops, but mostly because there is some
>>>>>> broadcasts and etc. tcpdump at the moment of such drops doesn't show
>>>>>> anything suspicious.
>>>>>> Changed qdisc from default fifo_fast to bfifo, without any result.
>>>>>> Tried: ethtool -K eth0 tso off gso off gro off sg off , no result
>>>>>> Problem occured at 3.3.6 - 3.4.0-rc7, most probably 3.3.0 also, but i
>>>>>> don't remember for sure. I thik on some kernels like 3.1 probably it
>>>>>> doesn't occur, i will check it soon, because it is not always reliable
>>>>>> to reproduce it. All tests i did on 3.4.0-rc7.
>>>>>>
>>>>>> I did run also in background tcpdump, additionally iptables with
>>>>>> timestamps, and at time when stall occured, seems i am still receiving
>>>>>> packets properly, also on iperf udp (from some host to this SunFire)
>>>>>> at this moments no packets missing. But i am sure RX interface errors
>>>>>> are increasing.
>>>>>> If i do iperf from SunFire to test host - there is packetloss at
>>>>>> moments when stall occured.
>>>>>>
>>>>>> I suspect that by some reason network card stop to transmit, but
>>>>>> unable to pinpoint issue. All other hosts in this network are fine and
>>>>>> don't have such problems.
>>>>>> Can you help me with that please? Maybe i can provide more debug
>>>>>> information, compile with patches and etc. Also i will try to fallback
>>>>>> to 3.1 and 3.0 kernels.
>>>>>>
>>>>>> Here it is how it occurs and i am reproducing it:
>>>>>> I'm just opening file, and start to scroll it in mc, then in another
>>>>>> console i run ping
>>>>>> [1337089061.844167] 1480 bytes from 194.146.153.20: icmp_req=162
>>>>>> ttl=64 time=0.485 ms
>>>>>> [1337089061.944138] 1480 bytes from 194.146.153.20: icmp_req=163
>>>>>> ttl=64 time=0.470 ms
>>>>>> [1337089062.467759] 1480 bytes from 194.146.153.20: icmp_req=164
>>>>>> ttl=64 time=424 ms
>>>>>> [1337089062.467899] 1480 bytes from 194.146.153.20: icmp_req=165
>>>>>> ttl=64 time=324 ms
>>>>>> [1337089062.468058] 1480 bytes from 194.146.153.20: icmp_req=166
>>>>>> ttl=64 time=214 ms
>>>>>> [1337089062.468161] 1480 bytes from 194.146.153.20: icmp_req=167
>>>>>> ttl=64 time=104 ms
>>>>>> [1337089062.468958] 1480 bytes from 194.146.153.20: icmp_req=168
>>>>>> ttl=64 time=1.15 ms
>>>>>> [1337089062.568604] 1480 bytes from 194.146.153.20: icmp_req=169
>>>>>> ttl=64 time=0.477 ms
>>>>>> [1337089062.668909] 1480 bytes from 194.146.153.20: icmp_req=170
>>>>>> ttl=64 time=0.667 ms
>>>>>>
>>>>>> Remote host tcpdump:
>>>>>> 1337089061.934737 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 163, length 1480
>>>>>> 1337089062.458360 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 164, length 1480
>>>>>> 1337089062.458380 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 164, length 1480
>>>>>> 1337089062.458481 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 165, length 1480
>>>>>> 1337089062.458502 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 165, length 1480
>>>>>> 1337089062.458606 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 166, length 1480
>>>>>> 1337089062.458623 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 166, length 1480
>>>>>> 1337089062.458729 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 167, length 1480
>>>>>> 1337089062.458745 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 167, length 1480
>>>>>> 1337089062.459537 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 168, length 1480
>>>>>> 1337089062.459545 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 168, length 1480
>>>>>>
>>>>>> Local host(SunFire) tcpdump:
>>>>>> 1337089061.844140 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 162, length 1480
>>>>>> 1337089061.943661 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 163, length 1480
>>>>>> 1337089061.944124 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 163, length 1480
>>>>>> 1337089062.465622 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 164, length 1480
>>>>>> 1337089062.465630 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 165, length 1480
>>>>>> 1337089062.465632 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 166, length 1480
>>>>>> 1337089062.465634 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 167, length 1480
>>>>>> 1337089062.467730 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 164, length 1480
>>>>>> 1337089062.467785 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 168, length 1480
>>>>>> 1337089062.467884 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 165, length 1480
>>>>>> 1337089062.468035 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 166, length 1480
>>>>>> 1337089062.468129 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 167, length 1480
>>>>>> 1337089062.468928 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 168, length 1480
>>>>>> 1337089062.568112 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 169, length 1480
>>>>>> 1337089062.568578 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 169, length 1480
>>>>>>
>>>>>> lspci -t
>>>>>> centaur src # lspci -t
>>>>>> -[0000:00]-+-00.0
>>>>>> +-02.0-[01-05]--+-00.0-[02-04]--+-00.0-[03]--
>>>>>> | | \-02.0-[04]--+-00.0
>>>>>> | | \-00.1
>>>>>> | \-00.3-[05]--
>>>>>> +-03.0-[06]--
>>>>>> +-04.0-[07]----00.0
>>>>>> +-05.0-[08]--
>>>>>> +-06.0-[09]--
>>>>>> +-07.0-[0a]--
>>>>>> +-08.0
>>>>>> +-10.0
>>>>>> +-10.1
>>>>>> +-10.2
>>>>>> +-11.0
>>>>>> +-13.0
>>>>>> +-15.0
>>>>>> +-16.0
>>>>>> +-1c.0-[0b]--+-00.0
>>>>>> | \-00.1
>>>>>> +-1d.0
>>>>>> +-1d.1
>>>>>> +-1d.2
>>>>>> +-1d.3
>>>>>> +-1d.7
>>>>>> +-1e.0-[0c]----05.0
>>>>>> +-1f.0
>>>>>> +-1f.1
>>>>>> +-1f.2
>>>>>> \-1f.3
>>>>>> lspci
>>>>>> 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory
>>>>>> Controller Hub (rev b1)
>>>>>> 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 2 (rev b1)
>>>>>> 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 3 (rev b1)
>>>>>> 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x8 Port 4-5 (rev b1)
>>>>>> 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 5 (rev b1)
>>>>>> 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x8 Port 6-7 (rev b1)
>>>>>> 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 7 (rev b1)
>>>>>> 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA
>>>>>> Engine (rev b1)
>>>>>> 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>> Registers (rev b1)
>>>>>> 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>> Registers (rev b1)
>>>>>> 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>> Registers (rev b1)
>>>>>> 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
>>>>>> Registers (rev b1)
>>>>>> 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
>>>>>> Registers (rev b1)
>>>>>> 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>> Registers (rev b1)
>>>>>> 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>> Registers (rev b1)
>>>>>> 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset
>>>>>> PCI Express Root Port 1 (rev 09)
>>>>>> 00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #1 (rev 09)
>>>>>> 00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #2 (rev 09)
>>>>>> 00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #3 (rev 09)
>>>>>> 00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #4 (rev 09)
>>>>>> 00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset EHCI USB2 Controller (rev 09)
>>>>>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
>>>>>> 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset
>>>>>> LPC Interface Controller (rev 09)
>>>>>> 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE
>>>>>> Controller (rev 09)
>>>>>> 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA AHCI
>>>>>> Controller (rev 09)
>>>>>> 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus
>>>>>> Controller (rev 09)
>>>>>> 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
>>>>>> Upstream Port (rev 01)
>>>>>> 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to
>>>>>> PCI-X Bridge (rev 01)
>>>>>> 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
>>>>>> Downstream Port E1 (rev 01)
>>>>>> 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
>>>>>> Downstream Port E3 (rev 01)
>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 07:00.0 RAID bus controller: Adaptec AAC-RAID (rev 09)
>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> 0c:05.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
>>>>>> Graphics Family
>>>>>>
>>>>>>
>>>>>> dmesg:
>>>>>> [ 4.936885] e1000: Intel(R) PRO/1000 Network Driver - version
>>>>>> 7.3.21-k8-NAPI
>>>>>> [ 4.936887] e1000: Copyright (c) 1999-2006 Intel Corporation.
>>>>>> [ 4.936966] e1000e: Intel(R) PRO/1000 Network Driver - 1.9.5-k
>>>>>> [ 4.936967] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
>>>>>> [ 4.938529] e1000e 0000:04:00.0: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 4.939598] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>> [ 4.992246] e1000e 0000:04:00.0: eth0: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:f8
>>>>>> [ 4.992657] e1000e 0000:04:00.0: eth0: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 4.992964] e1000e 0000:04:00.0: eth0: MAC: 5, PHY: 5, PBA No:
>>>>>> FFFFFF-0FF
>>>>>> [ 4.994745] e1000e 0000:04:00.1: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 4.996233] e1000e 0000:04:00.1: irq 66 for MSI/MSI-X
>>>>>> [ 5.050901] e1000e 0000:04:00.1: eth1: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:f9
>>>>>> [ 5.051317] e1000e 0000:04:00.1: eth1: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 5.051623] e1000e 0000:04:00.1: eth1: MAC: 5, PHY: 5, PBA No:
>>>>>> FFFFFF-0FF
>>>>>> [ 5.051857] e1000e 0000:0b:00.0: Disabling ASPM L1
>>>>>> [ 5.052168] e1000e 0000:0b:00.0: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 5.052611] e1000e 0000:0b:00.0: irq 67 for MSI/MSI-X
>>>>>> [ 5.223454] e1000e 0000:0b:00.0: eth2: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:fa
>>>>>> [ 5.223864] e1000e 0000:0b:00.0: eth2: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 5.224178] e1000e 0000:0b:00.0: eth2: MAC: 0, PHY: 4, PBA No:
>>>>>> C83246-002
>>>>>> [ 5.224412] e1000e 0000:0b:00.1: Disabling ASPM L1
>>>>>> [ 5.224709] e1000e 0000:0b:00.1: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 5.225168] e1000e 0000:0b:00.1: irq 68 for MSI/MSI-X
>>>>>> [ 5.397603] e1000e 0000:0b:00.1: eth3: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:fb
>>>>>> [ 5.398021] e1000e 0000:0b:00.1: eth3: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 5.398336] e1000e 0000:0b:00.1: eth3: MAC: 0, PHY: 4, PBA No:
>>>>>> C83246-002
>>>>>> [ 13.859817] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>> [ 13.962309] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>> [ 17.150392] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex,
>>>>>> Flow Control: None
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Network engineer
>>>>> Denys Fedoryshchenko
>>>>>
>>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>>> Beirut, Lebanon
>>>>> Tel: +961 1 247373
>>>>> E-Mail: denys@visp.net.lb
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> ---
>>>> Network engineer
>>>> Denys Fedoryshchenko
>>>>
>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>> Beirut, Lebanon
>>>> Tel: +961 1 247373
>>>> E-Mail: denys@visp.net.lb
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> ---
>>> Network engineer
>>> Denys Fedoryshchenko
>>>
>>> Dora Highway - Center Cebaco - 2nd Floor
>>> Beirut, Lebanon
>>> Tel: +961 1 247373
>>> E-Mail: denys@visp.net.lb
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> ---
> Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Paul Gortmaker @ 2012-05-20 16:41 UTC (permalink / raw)
To: Ondrej Zary; +Cc: davem, netdev, Alan Cox
In-Reply-To: <201205191058.45328.linux@rainbow-software.org>
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 19/05/2012 (Sat 10:58) Ondrej Zary wrote:
> On Saturday 19 May 2012 00:03:06 Paul Gortmaker wrote:
> > [Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On
> 18/05/2012 (Fri 20:16) Ondrej Zary wrote:
> > > On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote:
> > > > It was amusing that linux was able to make use of this 1980's
> > > > technology on machines long past its intended lifespan, but
> > > > it probably should go now -- it is causing issues in some
> > > > distros[1], and while that might be fixable, it is just not
> > > > worth it.
> > > >
> > > > [1]
> > > > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-c
> > > >ard- not-detecting-934344/
> > >
> > > That looks like a bug elsewhere and removing this driver will not fix it.
> >
> > You miss the point. We've got someone with a modern i7 machine who is
> > getting confused by seeing messages from some ancient 3c501 driver, but
> > he doesn't have the context to know it is ancient and the message is a
> > red herring. Will it fix a distro's broken init that tries to modprobe
> > everything? No. Will it help by not muddying the waters with
> > meaningless printk from 3c501 that confuse users? Yes.
>
> Are you going to remove all drivers that complain that the HW is not present
> because some broken script is trying to modprobe them all? Or only the first
> one? 3c501 is probably the first in alphabet. You remove that and the script
> will modprobe 3c503 then...
Per my other mail, I think to focus on this one user's issue misses the
bigger picture entirely; the real issue was called out in the commit log:
But from a functional point of view, the real issue, as stated
in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can
only do one thing at a time -- while you are removing one packet
from the single-packet buffer it cannot receive another packet,
nor can it receive a packet while loading a transmit packet."
Regardless, to answer your questions:
1) No, obviously an rm-rf of all drivers that can't probe quietly was
not going to happen; that was never implicilty or explicitly proposed.
2) From memory while working on the 3c503 driver 15 odd years ago, it
could probe silently and semi reliably, which was impressive then, given
it was pre ISA-PnP. It was worlds ahead of a 3c501 card.
Paul.
--
>
> --
> Ondrej Zary
^ permalink raw reply
* Re: [PATCH v5] tilegx network driver: initial support
From: Chris Metcalf @ 2012-05-20 16:35 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, arnd, linux-kernel, netdev
In-Reply-To: <1336744445.2874.57.camel@bwh-desktop.uk.solarflarecom.com>
On 5/11/2012 9:54 AM, Ben Hutchings wrote:
> Here's another very incomplete review for you.
Thanks, I (we) appreciate it!
>> +/* Define to support GSO. */
>> +#undef TILE_NET_GSO
> GSO is always enabled by the networking core.
>
>> +/* Define to support TSO. */
>> +#define TILE_NET_TSO
> No, put NETIF_F_TSO in hw_features so it can be switched at run-time.
We already had that; the TSO define was just to decide whether the driver
would even offer TSO support at all. But on reflection it seems pointless
not to offer TSO, so I've made it true unconditionally and deleted the
define. Similarly I got rid of the (totally pointless) GSO define and let
the core control whether it switches GSO on or not.
We are looking at GRO support for a following change, but obviously we need
to set up ethtool_ops for that first, so we'll be doing that as well.
>> +/* Use 3000 to enable the Linux Traffic Control (QoS) layer, else 0. */
>> +#define TILE_NET_TX_QUEUE_LEN 0
> This can be changed through sysfs, so there is no need for a compile-
> time option.
Fair enough, and in practice we don't change this default anyway, so I
eliminated it.
>> +/* Define to dump packets (prints out the whole packet on tx and rx). */
>> +#undef TILE_NET_DUMP_PACKETS
> Should really be controlled through a 'debug' module parameter (see
> netif_msg_init(), netif_msg_pktdata(), etc.)
We almost never use this functionality anyway, so for now, I've just
removed it. If we want to reintroduce something like it, we'll use the
netif_msg stuff.
>> + /* Reserve slots, or return NETDEV_TX_BUSY if "full". */
>> + slot = gxio_mpipe_equeue_try_reserve(equeue, num_frags);
>> + if (slot < 0) {
>> + local_irq_restore(irqflags);
>> + /* ISSUE: "Virtual device xxx asks to queue packet". */
>> + return NETDEV_TX_BUSY;
>> + }
> You're supposed to stop queues when they're full. And since that state
> appears to be per-CPU, I think this device needs to be multiqueue with
> one TX queue per CPU and ndo_select_queue defined accordingly.
>
> [...]
>
> I'm not convinced you should be processing completions here at all. But
> certainly you should have stopped the queue earlier rather than having
> to wait here.
This is a larger issue. We are working on improving performance in the
driver overall, and how we handle per-cpu or global queueing, how we stop
and restart the driver, etc., will be part of it. (The underlying mpipe
resources are not per-cpu, so it may or may not make sense to have the
driver believe it's multiqueue.) I added some placeholder comments and a
reference to our internal bug ID on this issue.
> You mustn't treat random fields to atomic_t. For one thing, atomic_t
> contains an int while stats are unsigned long...
>
> Also, you're adding cache contention between all your CPUs here. You
> should maintain these stats per-CPU and then sum them in
> tile_net_get_stats(). Then you can just use ordinary additions.
Oops, you're right that atomic_t is the wrong size. What I've done is
switch to atomic_long_t, but moved the cast to a separate
tile_net_stats_add() function that has a BUILD_BUG_ON() to validate that
the sizes match, and also a long comment explaining why tilegx's memory
network architecture makes atomic adds exactly the right kind of thing to
do here. It's easy to forget that 99% of the world has a model of atomics
based on the Intel architecture.
> [...]
>> +/* Ioctl commands. */
>> +static int tile_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>> +{
>> + return -EOPNOTSUPP;
>> +}
> So why define it at all?
Because a following patch (not yet posted to LKML) adds support for
SIOCSHWTSTAMP and the ioctl was originally written that way to put the
framework in place.
The few suggestions I didn't respond to directly where pretty
straightforward and I just implemented them as you suggested.
Thanks again! The revised patch will follow momentarily.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Paul Gortmaker @ 2012-05-20 16:08 UTC (permalink / raw)
To: Alan Cox; +Cc: Ondrej Zary, davem, netdev
In-Reply-To: <20120519133038.282d0a7d@bob.linux.org.uk>
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 19/05/2012 (Sat 13:30) Alan Cox wrote:
> > You miss the point. We've got someone with a modern i7 machine who is
> > getting confused by seeing messages from some ancient 3c501 driver,
> > but he doesn't have the context to know it is ancient and the message
> > is a red herring. Will it fix a distro's broken init that tries to
> > modprobe everything? No. Will it help by not muddying the waters
> > with meaningless printk from 3c501 that confuse users? Yes.
>
> That seems a totally bogus reason for removing stuff. The kernel cannot
> manage every possible distribution and user screw up. They have more
> variety so they will always win the battle.
Unfortunate that Ondrej's comment led folks to focus on the above as if
it was the primary reason. It was not. The sheer unusability of it as
a real networking interface in today's world (that I listed) was the
prime motivation for removal. It was barely useable in the 1995 world,
and I can't imagine it has got better with age.
Getting rid of possibly misleading messages like the printk in the i7
user's messages is just a fringe benefit. I can remove the text:
"-- it is causing issues in some distros, and while
that might be fixable, it is just not worth it."
from the commit log[1] and I think the remaining description still stands
on its own as being justified.
>
> Removing it because nobody is running one even in a museum might be a
> good reason, but then the driver still works fine.
I would suspect that is the case here though. Based on its limitations
(one operation at a time please) - I can't imagine that anyone anywhere
is running one (with the possible exception of one or maybe two informal
museusms?).
>
> Also btw: the 3c501 isn't all TTL it's integrated. The 3c500 is all
> TTL and an amazing beast, its so big it won't fit a 16bit slot as it
> has to drop down after the connector to get all the chips on.
It has been at least 15 years since I've seen one, and google couldn't
find me a picture, so I was going on memory. 3c501 definitely still had a
lot of discrete TTL chips for bus glue logic then, since I'm sure it was
a busy looking board.
>
> (and yes I have a 3c500)
I've never seen one of those, and I count myself lucky. :)
>
> However I don't think this is the right way to tackle the ethernet
> history situation. As with MCA we should pull *all* the real
> historical interest only bits in one go so it's immediately obvious
> where the break point is for all devices.
MCA was fortunately reasonably bounded in time -- i.e. it was confined
largely to things unfit for any use today. EISA is somewhat the same.
>
> That or we'll replace confused distros and uses with confused ancient
> machine owners, and the latter can be far more persistent and
> irritating ;)
>
> So should we dump ISA ?
Per Dave's comments, we'd have to restrict ISA in this context to mean
ISA _drivers_ that support _only_ physical pluggable 8/16bit ISA bus
cards. With possible inclusion of onboard chips that were only deployed
on ancient motherboards well over 10 years ago -- e.g. onboard aha154x.c
and etherexpress on lp486e board type stuff. Maybe that is what you
implicitly meant anyways?
But since ISA isn't as nicely bounded in time, I could easily envision
someone with a 1GHz socket370 P3 and an ISA SMC-Ultra PnP connected to a
cable modem in a closet somewhere. Sure, it is old, but it could be
still doing the job of a _reliable_ workhorse.
Replace SMC-ultra with 3c501 in the above, and the story falls apart and
becomes laughable. This is with no disrespect for the 3c501 driver. It
is purely from the hardware being of a different era. Both ISA, but one
is 10-15 years newer than the other.
If we throw away the ISA card drivers all at once, we'll end up keeping
some things well past their best before date, and throwing out some
stuff that might actually still be used by real people. This isn't at
all fatal in itself, but something to consider when weighing against the
value of a consistent "all this stuff goes away on day X" message.
That, and the inevitable inability to get a consensus "yes" for a large
removal of ISA _card_ drivers from a decision committee, made me think
that piecemeal was better than no action. If folks think I'm wrong on
the consensus part, I will gladly start forming an ISA _card_ driver
list of candidates for some yet to be determined scheduled removal...
Paul.
[1] http://patchwork.ozlabs.org/patch/160144/
--
> Alan
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Emmanuel Fusté @ 2012-05-20 16:02 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker
> On 18/05/2012 (Fri 20:16) Ondrej Zary wrote:
> > On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote:
> > > It was amusing that linux was able to make use of this 1980's
> > > technology on machines long past its intended lifespan, but
> > > it probably should go now -- it is causing issues in some
> > > distros[1], and while that might be fixable, it is just not
> > > worth it.
> > >
> > > [1]
> > > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-
> > >not-detecting-934344/
> >
> > That looks like a bug elsewhere and removing this driver will not fix it.
>
> You miss the point. We've got someone with a modern i7 machine who is
> getting confused by seeing messages from some ancient 3c501 driver, but
> he doesn't have the context to know it is ancient and the message is a
> red herring. Will it fix a distro's broken init that tries to modprobe
> everything? No. Will it help by not muddying the waters with
> meaningless printk from 3c501 that confuse users? Yes.
>
> Thanks,
> Paul.
>
> >
> > --
> > Ondrej Zary
Oh sh**, even if I could understand the arguments for the MCA part I
could not
agree anymore on this.
I you go to this road, kill the m68k architecture and four or five more and
remove half or more of the drivers.
"meaningless printk" ? kill the printk, not the driver. "confuse users" ?
which users ? What you call a users in you comments are people which
only use
mouse and graphic environments and for which printk are not for ...
Your whole patchset is build around the philosophy perfectly resumed by your
words:
"xxx is being removed, since the 20year old hardware simply isn't capable of
meeting today's software demands on CPU and memory resources."
Such subjective positions are not valid technicals arguments.
Following Linux since twenty years, I could say without making a big mistake
that this is not the Linux way of doing things. Linux would never be
what it is
today in term of pure code architecture if the easy way of removing
"disturbing"
and "obsolete in today standards" hardware support code was the way of doing
things.
But perhaps my old way of viewing things is no longer compatible with
the new
generations or in what Linux is going to be...
Emmanuel.
PS: My over reaction is PARTLY caused because of special historic symbol
3c501 hardware represent. It was one of the only (if not the only one)
ethernet
card supported by the Apollo platform and DomainOS. A great and
important part
of the computer / Unix history.
^ permalink raw reply
* [PATCH] ipv6/exthdrs: strict Pad1 and PadN check
From: Eldad Zack @ 2012-05-20 11:59 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel, Eldad Zack
The following tightens the padding check from commit
c1412fce7eccae62b4de22494f6ab3ff8a90c0c6 :
* Take into account combinations of consecutive Pad1 and PadN.
* Catch the corner case of when only padding is present in the
header, when the extention header length is 0 (i.e., 8 bytes).
In this case, the header would have exactly 6 bytes of padding:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Next Header : Hdr Ext Len=0 : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: Padding (Pad1 or PadN) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
---
net/ipv6/exthdrs.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 50ec95f..6447dc4 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -144,6 +144,7 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
const unsigned char *nh = skb_network_header(skb);
int off = skb_network_header_len(skb);
int len = (skb_transport_header(skb)[1] + 1) << 3;
+ int padlen = 0;
if (skb_transport_offset(skb) + len > skb_headlen(skb))
goto bad;
@@ -158,6 +159,9 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
switch (nh[off]) {
case IPV6_TLV_PAD1:
optlen = 1;
+ padlen++;
+ if (padlen > 7)
+ goto bad;
break;
case IPV6_TLV_PADN:
@@ -166,7 +170,8 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
* of 8. 7 is therefore the highest valid value.
* See also RFC 4942, Section 2.1.9.5.
*/
- if (optlen > 7)
+ padlen += optlen;
+ if (padlen > 7)
goto bad;
/* RFC 4942 recommends receiving hosts to
* actively check PadN payload to contain
@@ -195,11 +200,19 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
if (ip6_tlvopt_unknown(skb, off) == 0)
return false;
}
+ padlen = 0;
break;
}
off += optlen;
len -= optlen;
}
+ /* This case will not be caught by above check since its padding
+ * length is smaller than 7:
+ * 1 byte NH + 1 byte Length + 6 bytes Padding
+ */
+ if ((padlen == 6) && ((off - skb_network_header_len(skb)) == 8))
+ goto bad;
+
if (len == 0)
return true;
bad:
--
1.7.10
^ permalink raw reply related
* [PATCH RESENT] xen: do not disable netfront in dom0
From: Marek Marczykowski @ 2012-05-20 11:45 UTC (permalink / raw)
To: David Miller
Cc: Jeremy Fitzhardinge, Ian.Campbell, Konrad Rzeszutek Wilk, netdev,
Marek Marczykowski, xen-devel, virtualization, linux-kernel
In-Reply-To: <20120522194319.GA2691@phenom.dumpdata.com>
Netfront driver can be also useful in dom0, eg when all NICs are assigned to
some domU (aka driver domain). Then using netback in domU and netfront in dom0
is the only way to get network access in dom0.
Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
drivers/net/xen-netfront.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0ebbb19..2027afe 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1962,9 +1962,6 @@ static int __init netif_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_initial_domain())
- return 0;
-
if (xen_hvm_domain() && !xen_platform_pci_unplug)
return -ENODEV;
@@ -1977,9 +1974,6 @@ module_init(netif_init);
static void __exit netif_exit(void)
{
- if (xen_initial_domain())
- return;
-
xenbus_unregister_driver(&netfront_driver);
}
module_exit(netif_exit);
--
1.7.4.4
^ permalink raw reply related
* [PATCH] xen: do not disable netfront in dom0
From: Marek Marczykowski @ 2012-05-20 11:45 UTC (permalink / raw)
To: xen-devel
Cc: Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, netdev,
Marek Marczykowski, linux-kernel, virtualization
Netfront driver can be also useful in dom0, eg when all NICs are assigned to
some domU (aka driver domain). Then using netback in domU and netfront in dom0
is the only way to get network access in dom0.
Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
---
drivers/net/xen-netfront.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 698b905..e31ebff 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1953,9 +1953,6 @@ static int __init netif_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_initial_domain())
- return 0;
-
printk(KERN_INFO "Initialising Xen virtual ethernet driver.\n");
return xenbus_register_frontend(&netfront_driver);
@@ -1965,9 +1962,6 @@ module_init(netif_init);
static void __exit netif_exit(void)
{
- if (xen_initial_domain())
- return;
-
xenbus_unregister_driver(&netfront_driver);
}
module_exit(netif_exit);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 3/3] USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
From: Bjørn Mork @ 2012-05-20 10:53 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-3-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Acked-by: Bjørn Mork <bjorn@mork.no>
> /* ZTE suck at making USB descriptors */
> +static const struct driver_info qmi_wwan_force_int1 = {
> + .description = "Qualcomm WWAN/QMI device",
> + .flags = FLAG_WWAN,
> + .bind = qmi_wwan_bind_shared,
> + .unbind = qmi_wwan_unbind_shared,
> + .manage_power = qmi_wwan_manage_power,
> + .data = BIT(1), /* interface whitelist bitmap */
> +};
> +
> static const struct driver_info qmi_wwan_force_int4 = {
> .description = "Qualcomm WWAN/QMI device",
> .flags = FLAG_WWAN,
> @@ -430,6 +439,15 @@ static const struct usb_device_id products[] = {
> .bInterfaceProtocol = 0xff,
> .driver_info = (unsigned long)&qmi_wwan_force_int4,
> },
> + { /* ZTE (Vodafone) K3520-Z */
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x19d2,
> + .idProduct = 0x0055,
> + .bInterfaceClass = 0xff,
> + .bInterfaceSubClass = 0xff,
> + .bInterfaceProtocol = 0xff,
> + .driver_info = (unsigned long)&qmi_wwan_force_int1,
> + },
> { /* ZTE (Vodafone) K3565-Z */
> .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
> .idVendor = 0x19d2,
Looking forward to changing all this to a single line device + interface
number macro in 3.6 :-)
Bjørn
^ permalink raw reply
* Re: [PATCH 2/3] USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z
From: Bjørn Mork @ 2012-05-20 10:52 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-2-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Add the ZTE (Vodafone) K3765-Z to the whitelist.
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: [PATCH 1/3] USB: qmi_wwan: Make forced int 4 whitelist generic
From: Bjørn Mork @ 2012-05-20 10:50 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-1-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Change the forced interface 4 whitelist to use the generic shared
> binder instead of the Gobi specific one. Certain ZTE devices
> (K3520-Z & K3765-Z) don't work with the Gobi version, but function
> quite happily with the generic. This has been tested with the following
> devices:
> K3520-Z
> K3565-Z
> K3765-Z
> K4505-Z
> It hasn't been tested with the ZTE MF820D, which is the only other
> device that uses this whitelist at present. Although Bjorn doesn't
> expect any problems, any testing with that device would be appreciated.
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
> ---
> drivers/net/usb/qmi_wwan.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index d316503b..62a1a43 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -357,9 +357,9 @@ static const struct driver_info qmi_wwan_gobi = {
>
> /* ZTE suck at making USB descriptors */
> static const struct driver_info qmi_wwan_force_int4 = {
> - .description = "Qualcomm Gobi wwan/QMI device",
> + .description = "Qualcomm WWAN/QMI device",
> .flags = FLAG_WWAN,
> - .bind = qmi_wwan_bind_gobi,
> + .bind = qmi_wwan_bind_shared,
> .unbind = qmi_wwan_unbind_shared,
> .manage_power = qmi_wwan_manage_power,
> .data = BIT(4), /* interface whitelist bitmap */
Acked-by: Bjørn Mork <bjorn@mork.no>
This fixes a logical error in the code. Minidriver constructs with an
interface whitelist should not use qmi_wwan_bind_gobi. It was made to
prevent binding to the serial interfaces on Gobi devices, and serves no
useful purpose when used with a whitelist. The change is a no-op for
the ZTE MF820D, but is important for new devices.
Thanks for fixing this.
Bjør
^ permalink raw reply
* [PATCH 1/3] USB: qmi_wwan: Make forced int 4 whitelist generic
From: Andrew Bird @ 2012-05-20 8:28 UTC (permalink / raw)
To: bjorn; +Cc: gregkh, linux-usb, netdev, linux-kernel, Andrew Bird
Change the forced interface 4 whitelist to use the generic shared
binder instead of the Gobi specific one. Certain ZTE devices
(K3520-Z & K3765-Z) don't work with the Gobi version, but function
quite happily with the generic. This has been tested with the following
devices:
K3520-Z
K3565-Z
K3765-Z
K4505-Z
It hasn't been tested with the ZTE MF820D, which is the only other
device that uses this whitelist at present. Although Bjorn doesn't
expect any problems, any testing with that device would be appreciated.
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
---
drivers/net/usb/qmi_wwan.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index d316503b..62a1a43 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -357,9 +357,9 @@ static const struct driver_info qmi_wwan_gobi = {
/* ZTE suck at making USB descriptors */
static const struct driver_info qmi_wwan_force_int4 = {
- .description = "Qualcomm Gobi wwan/QMI device",
+ .description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_gobi,
+ .bind = qmi_wwan_bind_shared,
.unbind = qmi_wwan_unbind_shared,
.manage_power = qmi_wwan_manage_power,
.data = BIT(4), /* interface whitelist bitmap */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/3] USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
From: Andrew Bird @ 2012-05-20 8:28 UTC (permalink / raw)
To: bjorn; +Cc: gregkh, linux-usb, netdev, linux-kernel, Andrew Bird
In-Reply-To: <1337502518-1444-1-git-send-email-ajb@spheresystems.co.uk>
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
---
drivers/net/usb/qmi_wwan.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 0646e45..f64dac3 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -356,6 +356,15 @@ static const struct driver_info qmi_wwan_gobi = {
};
/* ZTE suck at making USB descriptors */
+static const struct driver_info qmi_wwan_force_int1 = {
+ .description = "Qualcomm WWAN/QMI device",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_shared,
+ .unbind = qmi_wwan_unbind_shared,
+ .manage_power = qmi_wwan_manage_power,
+ .data = BIT(1), /* interface whitelist bitmap */
+};
+
static const struct driver_info qmi_wwan_force_int4 = {
.description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
@@ -430,6 +439,15 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_force_int4,
},
+ { /* ZTE (Vodafone) K3520-Z */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x19d2,
+ .idProduct = 0x0055,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xff,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_force_int1,
+ },
{ /* ZTE (Vodafone) K3565-Z */
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
.idVendor = 0x19d2,
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z
From: Andrew Bird @ 2012-05-20 8:28 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bird
In-Reply-To: <1337502518-1444-1-git-send-email-ajb-5+cxppFmGx6/3pe1ocb+s/XRex20P6io@public.gmane.org>
Add the ZTE (Vodafone) K3765-Z to the whitelist. This requires the
previous patch to make the whitelist with forced interface 4 generic
or the device fails to initialise. After applying this patch and
loading the Option driver without usb-modeswitch's bind all
interfaces trick, a wwan0 net interface and /dev/cdc-wdm0 device
file were created. Using Bjorn Mork's perl connection script a
connection was made to a mobile network using QMI and the network
interface's IPv4 address was configured OK.
Signed-off-by: Andrew Bird <ajb-5+cxppFmGx6/3pe1ocb+s/XRex20P6io@public.gmane.org>
---
drivers/net/usb/qmi_wwan.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 62a1a43..0646e45 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -457,6 +457,15 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_force_int4,
},
+ { /* ZTE (Vodafone) K3765-Z */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x19d2,
+ .idProduct = 0x2002,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xff,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_force_int4,
+ },
{ /* ZTE (Vodafone) K4505-Z */
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
.idVendor = 0x19d2,
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] net/ipv4/ipconfig: neaten __setup placement
From: David Miller @ 2012-05-20 8:07 UTC (permalink / raw)
To: eldad; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1337472279-18615-1-git-send-email-eldad@fogrefinery.com>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Sun, 20 May 2012 02:04:39 +0200
> The __setup macro should follow the corresponding setup handler.
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/ipv4: replace simple_strtoul with kstrtoul
From: David Miller @ 2012-05-20 8:07 UTC (permalink / raw)
To: eldad; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1337472798-18913-1-git-send-email-eldad@fogrefinery.com>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Sun, 20 May 2012 02:13:18 +0200
> Replace simple_strtoul with kstrtoul in three similar occurrences, all setup
> handlers:
> * route.c: set_rhash_entries
> * tcp.c: set_thash_entries
> * udp.c: set_uhash_entries
>
> Also check if the conversion failed.
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Applied.
^ permalink raw reply
* [PATCH v6] tilegx network driver: initial support
From: Chris Metcalf @ 2012-05-20 4:42 UTC (permalink / raw)
To: Ben Hutchings, David Miller, arnd, linux-kernel, netdev
In-Reply-To: <1336744445.2874.57.camel@bwh-desktop.uk.solarflarecom.com>
This change adds support for the tilegx network driver based on the
GXIO IORPC support in the tilegx software stack, using the on-chip
mPIPE packet processing engine.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
---
drivers/net/ethernet/tile/Kconfig | 1 +
drivers/net/ethernet/tile/Makefile | 4 +-
drivers/net/ethernet/tile/tilegx.c | 1888 ++++++++++++++++++++++++++++++++++++
3 files changed, 1891 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/tile/tilegx.c
diff --git a/drivers/net/ethernet/tile/Kconfig b/drivers/net/ethernet/tile/Kconfig
index 2d9218f..9184b61 100644
--- a/drivers/net/ethernet/tile/Kconfig
+++ b/drivers/net/ethernet/tile/Kconfig
@@ -7,6 +7,7 @@ config TILE_NET
depends on TILE
default y
select CRC32
+ select TILE_GXIO_MPIPE if TILEGX
---help---
This is a standard Linux network device driver for the
on-chip Tilera Gigabit Ethernet and XAUI interfaces.
diff --git a/drivers/net/ethernet/tile/Makefile b/drivers/net/ethernet/tile/Makefile
index f634f14..0ef9eef 100644
--- a/drivers/net/ethernet/tile/Makefile
+++ b/drivers/net/ethernet/tile/Makefile
@@ -4,7 +4,7 @@
obj-$(CONFIG_TILE_NET) += tile_net.o
ifdef CONFIG_TILEGX
-tile_net-objs := tilegx.o mpipe.o iorpc_mpipe.o dma_queue.o
+tile_net-y := tilegx.o
else
-tile_net-objs := tilepro.o
+tile_net-y := tilepro.o
endif
diff --git a/drivers/net/ethernet/tile/tilegx.c b/drivers/net/ethernet/tile/tilegx.c
new file mode 100644
index 0000000..ab0d03e
--- /dev/null
+++ b/drivers/net/ethernet/tile/tilegx.c
@@ -0,0 +1,1888 @@
+/*
+ * Copyright 2012 Tilera Corporation. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation, version 2.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/moduleparam.h>
+#include <linux/sched.h>
+#include <linux/kernel.h> /* printk() */
+#include <linux/slab.h> /* kmalloc() */
+#include <linux/errno.h> /* error codes */
+#include <linux/types.h> /* size_t */
+#include <linux/interrupt.h>
+#include <linux/in.h>
+#include <linux/irq.h>
+#include <linux/netdevice.h> /* struct device, and other headers */
+#include <linux/etherdevice.h> /* eth_type_trans */
+#include <linux/skbuff.h>
+#include <linux/ioctl.h>
+#include <linux/cdev.h>
+#include <linux/hugetlb.h>
+#include <linux/in6.h>
+#include <linux/timer.h>
+#include <linux/io.h>
+#include <linux/ctype.h>
+#include <linux/ip.h>
+#include <linux/tcp.h>
+
+#include <asm/checksum.h>
+#include <asm/homecache.h>
+#include <gxio/mpipe.h>
+#include <arch/sim.h>
+
+
+/* Default transmit lockup timeout period, in jiffies. */
+#define TILE_NET_TIMEOUT (5 * HZ)
+
+/* The maximum number of distinct channels (idesc.channel is 5 bits). */
+#define TILE_NET_CHANNELS 32
+
+/* Maximum number of idescs to handle per "poll". */
+#define TILE_NET_BATCH 128
+
+/* Maximum number of packets to handle per "poll". */
+#define TILE_NET_WEIGHT 64
+
+/* Number of entries in each iqueue. */
+#define IQUEUE_ENTRIES 512
+
+/* Number of entries in each equeue. */
+#define EQUEUE_ENTRIES 2048
+
+/* Total header bytes per equeue slot. Must be big enough for 2 bytes
+ * of NET_IP_ALIGN alignment, plus 14 bytes (?) of L2 header, plus up to
+ * 60 bytes of actual TCP header. We round up to align to cache lines.
+ */
+#define HEADER_BYTES 128
+
+/* Maximum completions per cpu per device (must be a power of two).
+ * ISSUE: What is the right number here? If this is too small, then
+ * egress might block waiting for free space in a completions array.
+ * ISSUE: At the least, allocate these only for initialized echannels.
+ */
+#define TILE_NET_MAX_COMPS 64
+
+#define MAX_FRAGS (MAX_SKB_FRAGS + 1)
+
+MODULE_AUTHOR("Tilera Corporation");
+MODULE_LICENSE("GPL");
+
+/* A "packet fragment" (a chunk of memory). */
+struct frag {
+ void *buf;
+ size_t length;
+};
+
+/* A single completion. */
+struct tile_net_comp {
+ /* The "complete_count" when the completion will be complete. */
+ s64 when;
+ /* The buffer to be freed when the completion is complete. */
+ struct sk_buff *skb;
+};
+
+/* The completions for a given cpu and device. */
+struct tile_net_comps {
+ /* The completions. */
+ struct tile_net_comp comp_queue[TILE_NET_MAX_COMPS];
+ /* The number of completions used. */
+ unsigned long comp_next;
+ /* The number of completions freed. */
+ unsigned long comp_last;
+};
+
+/* Info for a specific cpu. */
+struct tile_net_info {
+ /* The NAPI struct. */
+ struct napi_struct napi;
+ /* Packet queue. */
+ gxio_mpipe_iqueue_t iqueue;
+ /* Our cpu. */
+ int my_cpu;
+ /* True if iqueue is valid. */
+ bool has_iqueue;
+ /* NAPI flags. */
+ bool napi_added;
+ bool napi_enabled;
+ /* Number of small sk_buffs which must still be provided. */
+ unsigned int num_needed_small_buffers;
+ /* Number of large sk_buffs which must still be provided. */
+ unsigned int num_needed_large_buffers;
+ /* A timer for handling egress completions. */
+ struct timer_list egress_timer;
+ /* True if "egress_timer" is scheduled. */
+ bool egress_timer_scheduled;
+ /* Comps for each egress channel. */
+ struct tile_net_comps *comps_for_echannel[TILE_NET_CHANNELS];
+};
+
+/* Info for egress on a particular egress channel. */
+struct tile_net_egress {
+ /* The "equeue". */
+ gxio_mpipe_equeue_t *equeue;
+ /* The headers for TSO. */
+ unsigned char *headers;
+};
+
+/* Info for a specific device. */
+struct tile_net_priv {
+ /* Our network device. */
+ struct net_device *dev;
+ /* The primary link. */
+ gxio_mpipe_link_t link;
+ /* The primary channel, if open, else -1. */
+ int channel;
+ /* The "loopify" egress link, if needed. */
+ gxio_mpipe_link_t loopify_link;
+ /* The "loopify" egress channel, if open, else -1. */
+ int loopify_channel;
+ /* The egress channel (channel or loopify_channel). */
+ int echannel;
+ /* Total stats. */
+ struct net_device_stats stats;
+};
+
+/* Egress info, indexed by "priv->echannel" (lazily created as needed). */
+static struct tile_net_egress egress_for_echannel[TILE_NET_CHANNELS];
+
+/* Devices currently associated with each channel.
+ * NOTE: The array entry can become NULL after ifconfig down, but
+ * we do not free the underlying net_device structures, so it is
+ * safe to use a pointer after reading it from this array.
+ */
+static struct net_device *tile_net_devs_for_channel[TILE_NET_CHANNELS];
+
+/* A mutex for "tile_net_devs_for_channel". */
+static DEFINE_MUTEX(tile_net_devs_for_channel_mutex);
+
+/* The per-cpu info. */
+static DEFINE_PER_CPU(struct tile_net_info, per_cpu_info);
+
+/* The "context" for all devices. */
+static gxio_mpipe_context_t context;
+
+/* The small/large "buffer stacks". */
+static int small_buffer_stack = -1;
+static int large_buffer_stack = -1;
+
+/* The buckets. */
+static int first_bucket = -1;
+static int num_buckets = 1;
+
+/* The ingress irq. */
+static int ingress_irq = -1;
+
+/* Text value of tile_net.cpus if passed as a module parameter. */
+static char *network_cpus_string;
+
+/* The actual cpus in "network_cpus". */
+static struct cpumask network_cpus_map;
+
+/* If "loopify=LINK" was specified, this is "LINK". */
+static char *loopify_link_name;
+
+/* If "tile_net.custom" was specified, this is non-NULL. */
+static char *custom_str;
+
+/* The "tile_net.cpus" argument specifies the cpus that are dedicated
+ * to handle ingress packets.
+ *
+ * The parameter should be in the form "tile_net.cpus=m-n[,x-y]", where
+ * m, n, x, y are integer numbers that represent the cpus that can be
+ * neither a dedicated cpu nor a dataplane cpu.
+ */
+static bool network_cpus_init(void)
+{
+ char buf[1024];
+ int rc;
+
+ if (network_cpus_string == NULL)
+ return false;
+
+ rc = cpulist_parse_crop(network_cpus_string, &network_cpus_map);
+ if (rc != 0) {
+ pr_warn("tile_net.cpus=%s: malformed cpu list\n",
+ network_cpus_string);
+ return false;
+ }
+
+ /* Remove dedicated cpus. */
+ cpumask_and(&network_cpus_map, &network_cpus_map, cpu_possible_mask);
+
+ if (cpumask_empty(&network_cpus_map)) {
+ pr_warn("Ignoring empty tile_net.cpus='%s'.\n",
+ network_cpus_string);
+ return false;
+ }
+
+ cpulist_scnprintf(buf, sizeof(buf), &network_cpus_map);
+ pr_info("Linux network CPUs: %s\n", buf);
+ return true;
+}
+
+module_param_named(cpus, network_cpus_string, charp, 0444);
+MODULE_PARM_DESC(cpus, "cpulist of cores that handle network interrupts");
+
+/* The "tile_net.loopify=LINK" argument causes the named device to
+ * actually use "loop0" for ingress, and "loop1" for egress. This
+ * allows an app to sit between the actual link and linux, passing
+ * (some) packets along to linux, and forwarding (some) packets sent
+ * out by linux.
+ */
+module_param_named(loopify, loopify_link_name, charp, 0444);
+MODULE_PARM_DESC(loopify, "name the device to use loop0/1 for ingress/egress");
+
+/* The "tile_net.custom" argument causes us to ignore the "conventional"
+ * classifier metadata, in particular, the "l2_offset".
+ */
+module_param_named(custom, custom_str, charp, 0444);
+MODULE_PARM_DESC(custom, "indicates a (heavily) customized classifier");
+
+/* Atomically update a statistics field.
+ * Note that on TILE-Gx, this operation is fire-and-forget on the
+ * issuing core (single-cycle dispatch) and takes only a few cycles
+ * longer than a regular store when the request reaches the home cache.
+ * No expensive bus management overhead is required.
+ */
+static void tile_net_stats_add(unsigned long value, unsigned long *field)
+{
+ BUILD_BUG_ON(sizeof(atomic_long_t) != sizeof(unsigned long));
+ atomic_long_add(value, (atomic_long_t *)field);
+}
+
+/* Allocate and push a buffer. */
+static bool tile_net_provide_buffer(bool small)
+{
+ int stack = small ? small_buffer_stack : large_buffer_stack;
+
+ /* Buffers must be aligned. */
+ const unsigned long align = 128;
+
+ /* Note that "dev_alloc_skb()" adds NET_SKB_PAD more bytes,
+ * and also "reserves" that many bytes.
+ */
+ int len = sizeof(struct sk_buff **) + align + (small ? 128 : 1664);
+
+ /* Allocate (or fail). */
+ struct sk_buff *skb = dev_alloc_skb(len);
+ if (skb == NULL)
+ return false;
+
+ /* Make room for a back-pointer to 'skb'. */
+ skb_reserve(skb, sizeof(struct sk_buff **));
+
+ /* Make sure we are aligned. */
+ skb_reserve(skb, -(long)skb->data & (align - 1));
+
+ /* Save a back-pointer to 'skb'. */
+ *(struct sk_buff **)(skb->data - sizeof(struct sk_buff **)) = skb;
+
+ /* Make sure "skb" and the back-pointer have been flushed. */
+ wmb();
+
+ gxio_mpipe_push_buffer(&context, stack,
+ (void *)va_to_tile_io_addr(skb->data));
+
+ return true;
+}
+
+static void tile_net_pop_all_buffers(int stack)
+{
+ void *va;
+ while ((va = gxio_mpipe_pop_buffer(&context, stack)) != NULL) {
+ struct sk_buff **skb_ptr = va - sizeof(*skb_ptr);
+ struct sk_buff *skb = *skb_ptr;
+ dev_kfree_skb_irq(skb);
+ }
+}
+
+/* Provide linux buffers to mPIPE. */
+static void tile_net_provide_needed_buffers(struct tile_net_info *info)
+{
+ while (info->num_needed_small_buffers != 0) {
+ if (!tile_net_provide_buffer(true))
+ goto oops;
+ info->num_needed_small_buffers--;
+ }
+
+ while (info->num_needed_large_buffers != 0) {
+ if (!tile_net_provide_buffer(false))
+ goto oops;
+ info->num_needed_large_buffers--;
+ }
+
+ return;
+
+oops:
+ /* Add a description to the page allocation failure dump. */
+ pr_notice("Tile %d still needs some buffers\n", info->my_cpu);
+}
+
+/* Handle a packet. Return true if "processed", false if "filtered". */
+static bool tile_net_handle_packet(struct tile_net_info *info,
+ gxio_mpipe_idesc_t *idesc)
+{
+ struct net_device *dev = tile_net_devs_for_channel[idesc->channel];
+ uint8_t l2_offset;
+ void *va;
+ void *buf;
+ unsigned long len;
+ int filter = 0;
+
+ /* Drop packets for which no buffer was available.
+ * NOTE: This happens under heavy load.
+ */
+ if (idesc->be) {
+ gxio_mpipe_iqueue_consume(&info->iqueue, idesc);
+ if (net_ratelimit())
+ pr_info("Dropping packet (insufficient buffers).\n");
+ return false;
+ }
+
+ /* Get the "l2_offset", if allowed. */
+ l2_offset = custom_str ? 0 : gxio_mpipe_idesc_get_l2_offset(idesc);
+
+ /* Get the raw buffer VA (includes "headroom"). */
+ va = tile_io_addr_to_va((unsigned long)(long)idesc->va);
+
+ /* Get the actual packet start/length. */
+ buf = va + l2_offset;
+ len = idesc->l2_size - l2_offset;
+
+ /* Point "va" at the raw buffer. */
+ va -= NET_IP_ALIGN;
+
+ if (dev != NULL) {
+ /* ISSUE: Is this needed? */
+ dev->last_rx = jiffies;
+ }
+
+ if (dev == NULL || !(dev->flags & IFF_UP)) {
+ /* Filter packets received before we're up. */
+ filter = 1;
+ } else if (!(dev->flags & IFF_PROMISC)) {
+ /* ISSUE: "eth_type_trans()" implies that "IFF_PROMISC"
+ * is set for "all silly devices", however, it appears
+ * to NOT be set for us, so this code here DOES run.
+ */
+ if (!is_multicast_ether_addr(buf)) {
+ /* Filter packets not for our address. */
+ const u8 *mine = dev->dev_addr;
+ filter = compare_ether_addr(mine, buf);
+ }
+ }
+
+ if (filter) {
+
+ /* ISSUE: Update "drop" statistics? */
+
+ gxio_mpipe_iqueue_drop(&info->iqueue, idesc);
+
+ } else {
+
+ struct tile_net_priv *priv = netdev_priv(dev);
+
+ /* Acquire the associated "skb". */
+ struct sk_buff **skb_ptr = va - sizeof(*skb_ptr);
+ struct sk_buff *skb = *skb_ptr;
+
+ /* Paranoia. */
+ if (skb->data != va) {
+ /* Panic here since there's a reasonable chance
+ * that corrupt buffers means generic memory
+ * corruption, with unpredictable system effects.
+ */
+ panic("Corrupt linux buffer! "
+ "buf=%p, skb=%p, skb->data=%p",
+ buf, skb, skb->data);
+ }
+
+ /* Skip headroom, and any custom header. */
+ skb_reserve(skb, NET_IP_ALIGN + l2_offset);
+
+ /* Encode the actual packet length. */
+ skb_put(skb, len);
+
+ /* NOTE: This call also sets "skb->dev = dev".
+ * ISSUE: The classifier provides us with "eth_type"
+ * (aka "eth->h_proto"), which is basically the value
+ * returned by "eth_type_trans()".
+ * Note that "eth_type_trans()" computes "skb->pkt_type",
+ * which would be useful for the "filter" check above,
+ * if we had a (modifiable) "skb" to work with.
+ */
+ skb->protocol = eth_type_trans(skb, dev);
+
+ /* Acknowledge "good" hardware checksums. */
+ if (idesc->cs && idesc->csum_seed_val == 0xFFFF)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+ netif_receive_skb(skb);
+
+ /* Update stats. */
+ tile_net_stats_add(1, &priv->stats.rx_packets);
+ tile_net_stats_add(len, &priv->stats.rx_bytes);
+
+ /* Need a new buffer. */
+ if (idesc->size == GXIO_MPIPE_BUFFER_SIZE_128)
+ info->num_needed_small_buffers++;
+ else
+ info->num_needed_large_buffers++;
+ }
+
+ gxio_mpipe_iqueue_consume(&info->iqueue, idesc);
+
+ return !filter;
+}
+
+/* Handle some packets for the current CPU.
+ *
+ * This function handles up to TILE_NET_BATCH idescs per call.
+ *
+ * ISSUE: Since we do not provide new buffers until this function is
+ * complete, we must initially provide enough buffers for each network
+ * cpu to fill its iqueue and also its batched idescs.
+ *
+ * ISSUE: The "rotting packet" race condition occurs if a packet
+ * arrives after the queue appears to be empty, and before the
+ * hypervisor interrupt is re-enabled.
+ */
+static int tile_net_poll(struct napi_struct *napi, int budget)
+{
+ struct tile_net_info *info = &__get_cpu_var(per_cpu_info);
+ unsigned int work = 0;
+ gxio_mpipe_idesc_t *idesc;
+ int i, n;
+
+ /* Process packets. */
+ while ((n = gxio_mpipe_iqueue_try_peek(&info->iqueue, &idesc)) > 0) {
+ for (i = 0; i < n; i++) {
+ if (i == TILE_NET_BATCH)
+ goto done;
+ if (tile_net_handle_packet(info, idesc + i)) {
+ if (++work >= budget)
+ goto done;
+ }
+ }
+ }
+
+ /* There are no packets left. */
+ napi_complete(&info->napi);
+
+ /* Re-enable hypervisor interrupts. */
+ gxio_mpipe_enable_notif_ring_interrupt(&context, info->iqueue.ring);
+
+ /* HACK: Avoid the "rotting packet" problem. */
+ if (gxio_mpipe_iqueue_try_peek(&info->iqueue, &idesc) > 0)
+ napi_schedule(&info->napi);
+
+ /* ISSUE: Handle completions? */
+
+done:
+ tile_net_provide_needed_buffers(info);
+
+ return work;
+}
+
+/* Handle an ingress interrupt on the current cpu. */
+static irqreturn_t tile_net_handle_ingress_irq(int irq, void *unused)
+{
+ struct tile_net_info *info = &__get_cpu_var(per_cpu_info);
+ napi_schedule(&info->napi);
+ return IRQ_HANDLED;
+}
+
+/* Free some completions. This must be called with interrupts blocked. */
+static void tile_net_free_comps(gxio_mpipe_equeue_t *equeue,
+ struct tile_net_comps *comps,
+ int limit, bool force_update)
+{
+ int n = 0;
+ while (comps->comp_last < comps->comp_next) {
+ unsigned int cid = comps->comp_last % TILE_NET_MAX_COMPS;
+ struct tile_net_comp *comp = &comps->comp_queue[cid];
+ if (!gxio_mpipe_equeue_is_complete(equeue, comp->when,
+ force_update || n == 0))
+ return;
+ dev_kfree_skb_irq(comp->skb);
+ comps->comp_last++;
+ if (++n == limit)
+ return;
+ }
+}
+
+/* Add a completion. This must be called with interrupts blocked.
+ *
+ * FIXME: We should probably have stopped the queue earlier rather
+ * than having to wait here.
+ */
+static void add_comp(gxio_mpipe_equeue_t *equeue,
+ struct tile_net_comps *comps,
+ uint64_t when, struct sk_buff *skb)
+{
+ int cid;
+
+ /* Wait for a free completion entry, if needed. */
+ while (comps->comp_next - comps->comp_last >= TILE_NET_MAX_COMPS - 1)
+ tile_net_free_comps(equeue, comps, 32, false);
+
+ /* Update the completions array. */
+ cid = comps->comp_next % TILE_NET_MAX_COMPS;
+ comps->comp_queue[cid].when = when;
+ comps->comp_queue[cid].skb = skb;
+ comps->comp_next++;
+}
+
+/* Make sure the egress timer is scheduled.
+ *
+ * Note that we use "schedule if not scheduled" logic instead of the more
+ * obvious "reschedule" logic, because "reschedule" is fairly expensive.
+ */
+static void tile_net_schedule_egress_timer(struct tile_net_info *info)
+{
+ if (!info->egress_timer_scheduled) {
+ mod_timer_pinned(&info->egress_timer, jiffies + 1);
+ info->egress_timer_scheduled = true;
+ }
+}
+
+/* The "function" for "info->egress_timer".
+ *
+ * This timer will reschedule itself as long as there are any pending
+ * completions expected for this tile.
+ */
+static void tile_net_handle_egress_timer(unsigned long arg)
+{
+ struct tile_net_info *info = (struct tile_net_info *)arg;
+ unsigned long irqflags;
+ bool pending = false;
+ int i;
+
+ local_irq_save(irqflags);
+
+ /* The timer is no longer scheduled. */
+ info->egress_timer_scheduled = false;
+
+ /* Free all possible comps for this tile. */
+ for (i = 0; i < TILE_NET_CHANNELS; i++) {
+ struct tile_net_egress *egress = &egress_for_echannel[i];
+ struct tile_net_comps *comps = info->comps_for_echannel[i];
+ if (comps->comp_last >= comps->comp_next)
+ continue;
+ tile_net_free_comps(egress->equeue, comps, -1, true);
+ pending = pending || (comps->comp_last < comps->comp_next);
+ }
+
+ /* Reschedule timer if needed. */
+ if (pending)
+ tile_net_schedule_egress_timer(info);
+
+ local_irq_restore(irqflags);
+}
+
+/* Prepare each CPU. */
+static void tile_net_prepare_cpu(void *unused)
+{
+ struct tile_net_info *info = &__get_cpu_var(per_cpu_info);
+ int my_cpu = smp_processor_id();
+
+ info->has_iqueue = false;
+
+ info->my_cpu = my_cpu;
+
+ /* Initialize the egress timer. */
+ init_timer(&info->egress_timer);
+ info->egress_timer.data = (long)info;
+ info->egress_timer.function = tile_net_handle_egress_timer;
+}
+
+/* Helper function for "tile_net_update()". */
+static void tile_net_update_cpu(void *arg)
+{
+ struct net_device *dev = arg;
+ struct tile_net_info *info = &__get_cpu_var(per_cpu_info);
+
+ if (info->has_iqueue) {
+ if (dev != NULL) {
+ if (!info->napi_added) {
+ netif_napi_add(dev, &info->napi,
+ tile_net_poll, TILE_NET_WEIGHT);
+ info->napi_added = true;
+ }
+ if (!info->napi_enabled) {
+ napi_enable(&info->napi);
+ info->napi_enabled = true;
+ }
+ enable_percpu_irq(ingress_irq, 0);
+ } else {
+ disable_percpu_irq(ingress_irq);
+ if (info->napi_enabled) {
+ napi_disable(&info->napi);
+ info->napi_enabled = false;
+ }
+ /* FIXME: Drain the iqueue. */
+ }
+ }
+}
+
+/* Helper function for tile_net_open() and tile_net_stop().
+ * Always called under tile_net_devs_for_channel_mutex.
+ */
+static int tile_net_update(struct net_device *dev)
+{
+ bool saw_channel = false;
+ int channel;
+ int rc;
+ int cpu;
+
+ /* This is too big to fit on the stack. */
+ static gxio_mpipe_rules_t rules;
+
+ gxio_mpipe_rules_init(&rules, &context);
+
+ for (channel = 0; channel < TILE_NET_CHANNELS; channel++) {
+ if (tile_net_devs_for_channel[channel] == NULL)
+ continue;
+ if (!saw_channel) {
+ saw_channel = true;
+ gxio_mpipe_rules_begin(&rules, first_bucket,
+ num_buckets, NULL);
+ gxio_mpipe_rules_set_headroom(&rules, NET_IP_ALIGN);
+ }
+ gxio_mpipe_rules_add_channel(&rules, channel);
+ }
+
+ /* NOTE: This can fail if there is no classifier.
+ * ISSUE: Can anything else cause it to fail?
+ */
+ rc = gxio_mpipe_rules_commit(&rules);
+ if (rc != 0) {
+ netdev_warn(dev, "gxio_mpipe_rules_commit failed: %d\n", rc);
+ return -EIO;
+ }
+
+ /* Update all cpus, sequentially (to protect "netif_napi_add()"). */
+ for_each_online_cpu(cpu)
+ smp_call_function_single(cpu, tile_net_update_cpu,
+ (saw_channel ? dev : NULL), 1);
+
+ /* HACK: Allow packets to flow in the simulator. */
+ if (saw_channel)
+ sim_enable_mpipe_links(0, -1);
+
+ return 0;
+}
+
+/* The first time any tilegx network device is opened, we initialize
+ * the global mpipe state. If this step fails, we fail to open the
+ * device, but if it succeeds, we never need to do it again, and since
+ * tile_net can't be unloaded, we never undo it.
+ *
+ * Note that some resources in this path (buffer stack indices,
+ * bindings from init_buffer_stack, etc.) are hypervisor resources
+ * that are freed simply via gxio_mpipe_destroy().
+ */
+static int tile_net_init_mpipe(struct net_device *dev)
+{
+ gxio_mpipe_buffer_size_enum_t small_buf_size =
+ GXIO_MPIPE_BUFFER_SIZE_128;
+ gxio_mpipe_buffer_size_enum_t large_buf_size =
+ GXIO_MPIPE_BUFFER_SIZE_1664;
+ size_t stack_bytes;
+ pte_t pte = { 0 };
+ void *small = NULL;
+ void *large = NULL;
+ int i, num_buffers, rc;
+ int network_cpus_count, cpu;
+ int ring, group, next_ring;
+ size_t comps_size = 0;
+ size_t notif_ring_size = 0;
+
+ if (!hash_default) {
+ netdev_err(dev, "Networking requires hash_default!\n");
+ return -EIO;
+ }
+
+ rc = gxio_mpipe_init(&context, 0);
+ if (rc != 0) {
+ netdev_err(dev, "gxio_mpipe_init failed: %d\n", rc);
+ return -EIO;
+ }
+
+ network_cpus_count = cpus_weight(network_cpus_map);
+
+ num_buffers =
+ network_cpus_count * (IQUEUE_ENTRIES + TILE_NET_BATCH);
+
+ /* Compute stack bytes; we round up to 64KB and then use
+ * alloc_pages() so we get the required 64KB alignment as well.
+ */
+ stack_bytes = ALIGN(gxio_mpipe_calc_buffer_stack_bytes(num_buffers),
+ 64 * 1024);
+
+ /* Allocate two buffer stack indices. */
+ rc = gxio_mpipe_alloc_buffer_stacks(&context, 2, 0, 0);
+ if (rc < 0) {
+ netdev_err(dev, "gxio_mpipe_alloc_buffer_stacks failed: %d\n",
+ rc);
+ goto fail;
+ }
+ small_buffer_stack = rc;
+ large_buffer_stack = rc + 1;
+
+ /* Allocate the small memory stack. */
+ small = alloc_pages_exact(stack_bytes, GFP_KERNEL);
+ if (small == NULL) {
+ netdev_err(dev,
+ "Could not alloc %zd bytes for buffer stacks\n",
+ stack_bytes);
+ rc = -ENOMEM;
+ goto fail;
+ }
+ rc = gxio_mpipe_init_buffer_stack(&context, small_buffer_stack,
+ small_buf_size,
+ small, stack_bytes, 0);
+ if (rc != 0) {
+ netdev_err(dev, "gxio_mpipe_init_buffer_stack: %d\n", rc);
+ goto fail;
+ }
+
+ /* Allocate the large buffer stack. */
+ large = alloc_pages_exact(stack_bytes, GFP_KERNEL);
+ if (large == NULL) {
+ netdev_err(dev,
+ "Could not alloc %zd bytes for buffer stacks\n",
+ stack_bytes);
+ rc = -ENOMEM;
+ goto fail;
+ }
+ rc = gxio_mpipe_init_buffer_stack(&context, large_buffer_stack,
+ large_buf_size,
+ large, stack_bytes, 0);
+ if (rc != 0) {
+ netdev_err(dev, "gxio_mpipe_init_buffer_stack failed: %d\n",
+ rc);
+ goto fail;
+ }
+
+ /* Register all the client memory in mpipe TLBs. */
+ pte = pte_set_home(pte, PAGE_HOME_HASH);
+ rc = gxio_mpipe_register_client_memory(&context, small_buffer_stack,
+ pte, 0);
+ if (rc != 0) {
+ netdev_err(dev,
+ "gxio_mpipe_register_buffer_memory failed: %d\n",
+ rc);
+ goto fail;
+ }
+ rc = gxio_mpipe_register_client_memory(&context, large_buffer_stack,
+ pte, 0);
+ if (rc != 0) {
+ netdev_err(dev,
+ "gxio_mpipe_register_buffer_memory failed: %d\n",
+ rc);
+ goto fail;
+ }
+
+ /* Provide initial buffers. */
+ rc = -ENOMEM;
+ for (i = 0; i < num_buffers; i++) {
+ if (!tile_net_provide_buffer(true)) {
+ netdev_err(dev, "Cannot allocate initial sk_bufs!\n");
+ goto fail_pop;
+ }
+ }
+ for (i = 0; i < num_buffers; i++) {
+ if (!tile_net_provide_buffer(false)) {
+ netdev_err(dev, "Cannot allocate initial sk_bufs!\n");
+ goto fail_pop;
+ }
+ }
+
+ /* Allocate one NotifRing for each network cpu. */
+ rc = gxio_mpipe_alloc_notif_rings(&context, network_cpus_count,
+ 0, 0);
+ if (rc < 0) {
+ netdev_err(dev, "gxio_mpipe_alloc_notif_rings failed %d\n",
+ rc);
+ goto fail_pop;
+ }
+
+ /* Init NotifRings. */
+ ring = rc;
+ next_ring = rc;
+
+ /* ISSUE: This is more than strictly necessary. */
+ comps_size = TILE_NET_CHANNELS * sizeof(struct tile_net_comps);
+
+ notif_ring_size = IQUEUE_ENTRIES * sizeof(gxio_mpipe_idesc_t);
+
+ for_each_online_cpu(cpu) {
+
+ int order;
+ struct page *page;
+ void *addr;
+
+ struct tile_net_info *info = &per_cpu(per_cpu_info, cpu);
+
+ /* Allocate the "comps". */
+ order = get_order(comps_size);
+ page = homecache_alloc_pages(GFP_KERNEL, order, cpu);
+ if (page == NULL) {
+ netdev_err(dev,
+ "Failed to alloc %zd bytes comps memory\n",
+ comps_size);
+ rc = -ENOMEM;
+ goto fail_pop;
+ }
+
+ addr = pfn_to_kaddr(page_to_pfn(page));
+ memset(addr, 0, comps_size);
+ for (i = 0; i < TILE_NET_CHANNELS; i++)
+ info->comps_for_echannel[i] =
+ addr + i * sizeof(struct tile_net_comps);
+
+ /* Only network cpus can receive packets. */
+ if (!cpu_isset(cpu, network_cpus_map))
+ continue;
+
+ /* Allocate the actual idescs array. */
+ order = get_order(notif_ring_size);
+ page = homecache_alloc_pages(GFP_KERNEL, order, cpu);
+ if (page == NULL) {
+ netdev_err(dev,
+ "Failed to alloc %zd bytes iqueue memory\n",
+ notif_ring_size);
+ rc = -ENOMEM;
+ goto fail_pop;
+ }
+ addr = pfn_to_kaddr(page_to_pfn(page));
+ rc = gxio_mpipe_iqueue_init(&info->iqueue, &context, next_ring,
+ addr, notif_ring_size, 0);
+ if (rc != 0) {
+ netdev_err(dev,
+ "gxio_mpipe_iqueue_init failed: %d\n", rc);
+ goto fail_pop;
+ }
+
+ info->has_iqueue = true;
+
+ next_ring++;
+ }
+
+ /* Allocate one NotifGroup. */
+ rc = gxio_mpipe_alloc_notif_groups(&context, 1, 0, 0);
+ if (rc < 0) {
+ netdev_err(dev, "gxio_mpipe_alloc_notif_groups failed: %d\n",
+ rc);
+ goto fail_pop;
+ }
+ group = rc;
+
+ if (network_cpus_count > 4)
+ num_buckets = 256;
+ else if (network_cpus_count > 1)
+ num_buckets = 16;
+
+ /* Allocate some buckets. */
+ rc = gxio_mpipe_alloc_buckets(&context, num_buckets, 0, 0);
+ if (rc < 0) {
+ netdev_err(dev, "gxio_mpipe_alloc_buckets failed: %d\n", rc);
+ goto fail_pop;
+ }
+ first_bucket = rc;
+
+ /* Init group and buckets. */
+ rc = gxio_mpipe_init_notif_group_and_buckets(
+ &context, group, ring, network_cpus_count,
+ first_bucket, num_buckets,
+ GXIO_MPIPE_BUCKET_STICKY_FLOW_LOCALITY);
+
+ if (rc != 0) {
+ netdev_err(
+ dev,
+ "gxio_mpipe_init_notif_group_and_buckets failed: %d\n",
+ rc);
+ goto fail_pop;
+ }
+
+ /* Create an irq and register it. Note that "ingress_irq" being
+ * initialized is how we know not to call this function again.
+ */
+ rc = create_irq();
+ if (rc < 0) {
+ netdev_err(dev, "create_irq failed: %d\n", rc);
+ goto fail_pop;
+
+ }
+ ingress_irq = rc;
+ tile_irq_activate(ingress_irq, TILE_IRQ_PERCPU);
+ rc = request_irq(ingress_irq, tile_net_handle_ingress_irq,
+ 0, NULL, NULL);
+ if (rc != 0) {
+ netdev_err(dev, "request_irq failed: %d\n", rc);
+ destroy_irq(ingress_irq);
+ ingress_irq = -1;
+ goto fail_pop;
+ }
+
+ for_each_online_cpu(cpu) {
+ struct tile_net_info *info = &per_cpu(per_cpu_info, cpu);
+ if (info->has_iqueue) {
+ gxio_mpipe_request_notif_ring_interrupt(
+ &context, cpu_x(cpu), cpu_y(cpu),
+ 1, ingress_irq, info->iqueue.ring);
+ }
+ }
+
+ return 0;
+
+fail_pop:
+ /* Do cleanups that require the mpipe context first. */
+ tile_net_pop_all_buffers(small_buffer_stack);
+ tile_net_pop_all_buffers(large_buffer_stack);
+
+fail:
+ /* Destroy mpipe context so the hardware no longer owns any memory. */
+ gxio_mpipe_destroy(&context);
+
+ for_each_online_cpu(cpu) {
+ struct tile_net_info *info = &per_cpu(per_cpu_info, cpu);
+ free_pages((unsigned long)(info->comps_for_echannel[0]),
+ get_order(comps_size));
+ info->comps_for_echannel[0] = NULL;
+ free_pages((unsigned long)(info->iqueue.idescs),
+ get_order(notif_ring_size));
+ info->iqueue.idescs = NULL;
+ }
+
+ if (small)
+ free_pages_exact(small, stack_bytes);
+ if (large)
+ free_pages_exact(large, stack_bytes);
+
+ large_buffer_stack = -1;
+ small_buffer_stack = -1;
+ first_bucket = -1;
+
+ return rc;
+}
+
+/* Create persistent egress info for a given egress channel.
+ *
+ * Note that this may be shared between, say, "gbe0" and "xgbe0".
+ *
+ * ISSUE: Defer header allocation until TSO is actually needed?
+ */
+static int tile_net_init_egress(struct net_device *dev, int echannel)
+{
+ struct page *headers_page, *edescs_page, *equeue_page;
+ gxio_mpipe_edesc_t *edescs;
+ gxio_mpipe_equeue_t *equeue;
+ unsigned char *headers;
+ int headers_order, edescs_order, equeue_order;
+ size_t edescs_size;
+ int edma;
+ int rc = -ENOMEM;
+
+ /* Only initialize once. */
+ if (egress_for_echannel[echannel].equeue != NULL)
+ return 0;
+
+ /* Allocate memory for the "headers". */
+ headers_order = get_order(EQUEUE_ENTRIES * HEADER_BYTES);
+ headers_page = alloc_pages(GFP_KERNEL, headers_order);
+ if (headers_page == NULL) {
+ netdev_warn(dev,
+ "Could not alloc %zd bytes for TSO headers.\n",
+ PAGE_SIZE << headers_order);
+ goto fail;
+ }
+ headers = pfn_to_kaddr(page_to_pfn(headers_page));
+
+ /* Allocate memory for the "edescs". */
+ edescs_size = EQUEUE_ENTRIES * sizeof(*edescs);
+ edescs_order = get_order(edescs_size);
+ edescs_page = alloc_pages(GFP_KERNEL, edescs_order);
+ if (edescs_page == NULL) {
+ netdev_warn(dev,
+ "Could not alloc %zd bytes for eDMA ring.\n",
+ edescs_size);
+ goto fail_headers;
+ }
+ edescs = pfn_to_kaddr(page_to_pfn(edescs_page));
+
+ /* Allocate memory for the "equeue". */
+ equeue_order = get_order(sizeof(*equeue));
+ equeue_page = alloc_pages(GFP_KERNEL, equeue_order);
+ if (equeue_page == NULL) {
+ netdev_warn(dev,
+ "Could not alloc %zd bytes for equeue info.\n",
+ PAGE_SIZE << equeue_order);
+ goto fail_edescs;
+ }
+ equeue = pfn_to_kaddr(page_to_pfn(equeue_page));
+
+ /* Allocate an edma ring. Note that in practice this can't
+ * fail, which is good, because we will leak an edma ring if so.
+ */
+ rc = gxio_mpipe_alloc_edma_rings(&context, 1, 0, 0);
+ if (rc < 0) {
+ netdev_warn(dev, "gxio_mpipe_alloc_edma_rings failed: %d\n",
+ rc);
+ goto fail_equeue;
+ }
+ edma = rc;
+
+ /* Initialize the equeue. */
+ rc = gxio_mpipe_equeue_init(equeue, &context, edma, echannel,
+ edescs, edescs_size, 0);
+ if (rc != 0) {
+ netdev_err(dev, "gxio_mpipe_equeue_init failed: %d\n", rc);
+ goto fail_equeue;
+ }
+
+ /* Done. */
+ egress_for_echannel[echannel].equeue = equeue;
+ egress_for_echannel[echannel].headers = headers;
+ return 0;
+
+fail_equeue:
+ __free_pages(equeue_page, equeue_order);
+
+fail_edescs:
+ __free_pages(edescs_page, edescs_order);
+
+fail_headers:
+ __free_pages(headers_page, headers_order);
+
+fail:
+ return rc;
+}
+
+/* Return channel number for a newly-opened link. */
+static int tile_net_link_open(struct net_device *dev, gxio_mpipe_link_t *link,
+ const char *link_name)
+{
+ int rc = gxio_mpipe_link_open(link, &context, link_name, 0);
+ if (rc < 0) {
+ netdev_err(dev, "Failed to open '%s'\n", link_name);
+ return rc;
+ }
+ rc = gxio_mpipe_link_channel(link);
+ if (rc < 0 || rc >= TILE_NET_CHANNELS) {
+ netdev_err(dev, "gxio_mpipe_link_channel bad value: %d\n", rc);
+ gxio_mpipe_link_close(link);
+ return -EINVAL;
+ }
+ return rc;
+}
+
+/* Help the kernel activate the given network interface. */
+static int tile_net_open(struct net_device *dev)
+{
+ struct tile_net_priv *priv = netdev_priv(dev);
+ int rc;
+
+ mutex_lock(&tile_net_devs_for_channel_mutex);
+
+ /* Do one-time initialization the first time any device is opened. */
+ if (ingress_irq < 0) {
+ rc = tile_net_init_mpipe(dev);
+ if (rc != 0)
+ goto fail;
+ }
+
+ /* Determine if this is the "loopify" device. */
+ if (unlikely((loopify_link_name != NULL) &&
+ !strcmp(dev->name, loopify_link_name))) {
+ rc = tile_net_link_open(dev, &priv->link, "loop0");
+ if (rc < 0)
+ goto fail;
+ priv->channel = rc;
+ rc = tile_net_link_open(dev, &priv->loopify_link, "loop1");
+ if (rc < 0)
+ goto fail;
+ priv->loopify_channel = rc;
+ priv->echannel = rc;
+ } else {
+ rc = tile_net_link_open(dev, &priv->link, dev->name);
+ if (rc < 0)
+ goto fail;
+ priv->channel = rc;
+ priv->echannel = rc;
+ }
+
+ /* Initialize egress info (if needed). Once ever, per echannel. */
+ rc = tile_net_init_egress(dev, priv->echannel);
+ if (rc != 0)
+ goto fail;
+
+ tile_net_devs_for_channel[priv->channel] = dev;
+
+ rc = tile_net_update(dev);
+ if (rc != 0)
+ goto fail;
+
+ mutex_unlock(&tile_net_devs_for_channel_mutex);
+
+ /* Start our transmit queue. */
+ netif_start_queue(dev);
+
+ netif_carrier_on(dev);
+
+ return 0;
+
+fail:
+ if (priv->loopify_channel >= 0) {
+ if (gxio_mpipe_link_close(&priv->loopify_link) != 0)
+ netdev_warn(dev, "Failed to close loopify link!\n");
+ priv->loopify_channel = -1;
+ }
+ if (priv->channel >= 0) {
+ if (gxio_mpipe_link_close(&priv->link) != 0)
+ netdev_warn(dev, "Failed to close link!\n");
+ priv->channel = -1;
+ }
+
+ priv->echannel = -1;
+
+ tile_net_devs_for_channel[priv->channel] = NULL;
+
+ mutex_unlock(&tile_net_devs_for_channel_mutex);
+
+ /* Don't return raw gxio error codes to generic Linux. */
+ return (rc > -512) ? rc : -EIO;
+}
+
+/* Help the kernel deactivate the given network interface. */
+static int tile_net_stop(struct net_device *dev)
+{
+ struct tile_net_priv *priv = netdev_priv(dev);
+
+ /* Stop our transmit queue. */
+ netif_stop_queue(dev);
+
+ mutex_lock(&tile_net_devs_for_channel_mutex);
+
+ tile_net_devs_for_channel[priv->channel] = NULL;
+
+ (void)tile_net_update(dev);
+
+ if (priv->loopify_channel >= 0) {
+ if (gxio_mpipe_link_close(&priv->loopify_link) != 0)
+ netdev_warn(dev, "Failed to close loopify link!\n");
+ priv->loopify_channel = -1;
+ }
+
+ if (priv->channel >= 0) {
+ if (gxio_mpipe_link_close(&priv->link) != 0)
+ netdev_warn(dev, "Failed to close link!\n");
+ priv->channel = -1;
+ }
+
+ priv->echannel = -1;
+
+ mutex_unlock(&tile_net_devs_for_channel_mutex);
+
+ return 0;
+}
+
+/* Determine the VA for a fragment. */
+static inline void *tile_net_frag_buf(skb_frag_t *f)
+{
+ unsigned long pfn = page_to_pfn(skb_frag_page(f));
+ return pfn_to_kaddr(pfn) + f->page_offset;
+}
+
+/* Used for paranoia to make sure we handle no ill-formed packets. */
+#define TSO_DROP_IF(cond) \
+ do { if (WARN_ON(cond)) return NETDEV_TX_OK; } while (0)
+
+
+/* This function takes "skb", consisting of a header template and a
+ * (presumably) huge payload, and egresses it as one or more segments
+ * (aka packets), each consisting of a (possibly modified) copy of the
+ * header plus a piece of the payload, via "tcp segmentation offload".
+ *
+ * Usually, "data" will contain the header template, of size "sh_len",
+ * and "sh->frags" will contain "skb->data_len" bytes of payload, and
+ * there will be "sh->gso_segs" segments.
+ *
+ * Sometimes, if "sendfile()" requires copying, we will be called with
+ * "data" containing the header and payload, with "frags" being empty.
+ *
+ * Sometimes, for example when using NFS over TCP, a single segment can
+ * span 3 fragments. This requires special care below.
+ *
+ * See "emulate_large_send_offload()" for some reference code, which
+ * does not handle checksumming.
+ */
+static int tile_net_tx_tso(struct sk_buff *skb, struct net_device *dev)
+{
+ struct tile_net_priv *priv = netdev_priv(dev);
+
+ struct tile_net_info *info = &__get_cpu_var(per_cpu_info);
+
+ struct tile_net_egress *egress = &egress_for_echannel[priv->echannel];
+ gxio_mpipe_equeue_t *equeue = egress->equeue;
+
+ struct tile_net_comps *comps =
+ info->comps_for_echannel[priv->echannel];
+
+ unsigned int len = skb->len;
+ unsigned char *data = skb->data;
+
+ /* The ip header follows the ethernet header. */
+ struct iphdr *ih = ip_hdr(skb);
+ unsigned int ih_len = ih->ihl * 4;
+
+ /* Note that "nh == iph", by definition. */
+ unsigned char *nh = skb_network_header(skb);
+ unsigned int eh_len = nh - data;
+
+ /* The tcp header follows the ip header. */
+ struct tcphdr *th = (struct tcphdr *)(nh + ih_len);
+ unsigned int th_len = th->doff * 4;
+
+ /* The total number of header bytes. */
+ unsigned int sh_len = eh_len + ih_len + th_len;
+
+ /* Help compute "jh->check". */
+ unsigned int isum_hack =
+ ((0xFFFF - ih->check) +
+ (0xFFFF - ih->tot_len) +
+ (0xFFFF - ih->id));
+
+ /* Help compute "uh->check". */
+ unsigned int tsum_hack = th->check + (0xFFFF ^ htons(len));
+
+ struct skb_shared_info *sh = skb_shinfo(skb);
+
+ /* The maximum payload size. */
+ unsigned int gso_size = sh->gso_size;
+
+ /* The size of the initial segments (including header). */
+ unsigned int mtu = sh_len + gso_size;
+
+ /* The size of the final segment (including header). */
+ unsigned int mtu2 = len - ((sh->gso_segs - 1) * gso_size);
+
+ /* Track tx stats. */
+ unsigned int tx_packets = 0;
+ unsigned int tx_bytes = 0;
+
+ /* Which segment are we on. */
+ unsigned int segment;
+
+ /* Get the initial ip "id". */
+ u16 id = ntohs(ih->id);
+
+ /* Get the initial tcp "seq". */
+ u32 seq = ntohl(th->seq);
+
+ /* The id of the current fragment (or -1). */
+ long f_id;
+
+ /* The size of the current fragment (or -1). */
+ long f_size;
+
+ /* The bytes used from the current fragment (or -1). */
+ long f_used;
+
+ /* The size of the current piece of payload. */
+ long n;
+
+ /* Prepare checksum info. */
+ unsigned int csum_start = skb_checksum_start_offset(skb);
+
+ /* The header/payload edesc's. */
+ gxio_mpipe_edesc_t edesc_head = { { 0 } };
+ gxio_mpipe_edesc_t edesc_body = { { 0 } };
+
+ /* Total number of edescs needed. */
+ unsigned int num_edescs = 0;
+
+ unsigned long irqflags;
+
+ /* First reserved egress slot. */
+ s64 slot;
+
+ /* Empty packets (etc) would cause trouble below. */
+ TSO_DROP_IF(skb->data_len == 0);
+ TSO_DROP_IF(sh->nr_frags == 0);
+ TSO_DROP_IF(sh->gso_segs == 0);
+
+ /* We assume the frags contain the entire payload. */
+ TSO_DROP_IF(skb_headlen(skb) != sh_len);
+ TSO_DROP_IF(len != sh_len + skb->data_len);
+
+ /* Implicitly verify "gso_segs" and "gso_size". */
+ TSO_DROP_IF(mtu2 > mtu);
+
+ /* We only have HEADER_BYTES for each header. */
+ TSO_DROP_IF(NET_IP_ALIGN + sh_len > HEADER_BYTES);
+
+ /* Paranoia. */
+ TSO_DROP_IF(skb->protocol != htons(ETH_P_IP));
+ TSO_DROP_IF(ih->protocol != IPPROTO_TCP);
+ TSO_DROP_IF(skb->ip_summed != CHECKSUM_PARTIAL);
+ TSO_DROP_IF(csum_start != eh_len + ih_len);
+
+ /* Prepare to egress the headers. */
+ edesc_head.csum = 1;
+ edesc_head.csum_start = csum_start;
+ edesc_head.csum_dest = csum_start + skb->csum_offset;
+ edesc_head.xfer_size = sh_len;
+
+ /* This is only used to specify the TLB. */
+ edesc_head.stack_idx = large_buffer_stack;
+ edesc_body.stack_idx = large_buffer_stack;
+
+ /* Reset. */
+ f_id = -1;
+ f_size = -1;
+ f_used = -1;
+
+ /* Determine how many edesc's are needed. */
+ for (segment = 0; segment < sh->gso_segs; segment++) {
+
+ /* Detect the final segment. */
+ bool final = (segment == sh->gso_segs - 1);
+
+ /* The segment size (including header). */
+ unsigned int s_len = final ? mtu2 : mtu;
+
+ /* The size of the payload. */
+ unsigned int p_len = s_len - sh_len;
+
+ /* The bytes used from the payload. */
+ unsigned int p_used = 0;
+
+ /* One edesc for the header. */
+ num_edescs++;
+
+ /* One edesc for each piece of the payload. */
+ while (p_used < p_len) {
+
+ /* Advance as needed. */
+ while (f_used >= f_size) {
+ f_id++;
+ f_size = sh->frags[f_id].size;
+ f_used = 0;
+ }
+
+ /* Use bytes from the current fragment. */
+ n = p_len - p_used;
+ if (n > f_size - f_used)
+ n = f_size - f_used;
+ f_used += n;
+ p_used += n;
+
+ num_edescs++;
+ }
+ }
+
+ /* Verify all fragments consumed. */
+ TSO_DROP_IF(f_id + 1 != sh->nr_frags);
+ TSO_DROP_IF(f_used != f_size);
+
+ local_irq_save(irqflags);
+
+ /* See comment in tile_net_tx(). */
+ slot = gxio_mpipe_equeue_try_reserve(equeue, num_edescs);
+ if (slot < 0) {
+ local_irq_restore(irqflags);
+ return NETDEV_TX_BUSY;
+ }
+
+ /* Reset. */
+ f_id = -1;
+ f_size = -1;
+ f_used = -1;
+
+ /* Prepare all the headers. */
+ for (segment = 0; segment < sh->gso_segs; segment++) {
+
+ /* Detect the final segment. */
+ bool final = (segment == sh->gso_segs - 1);
+
+ /* The segment size (including header). */
+ unsigned int s_len = final ? mtu2 : mtu;
+
+ /* The size of the payload. */
+ unsigned int p_len = s_len - sh_len;
+
+ /* The bytes used from the payload. */
+ unsigned int p_used = 0;
+
+ /* Access the header memory for this segment. */
+ unsigned int bn = slot % EQUEUE_ENTRIES;
+ unsigned char *buf =
+ egress->headers + bn * HEADER_BYTES + NET_IP_ALIGN;
+
+ /* The soon-to-be copied "ip" header. */
+ struct iphdr *jh = (struct iphdr *)(buf + eh_len);
+
+ /* The soon-to-be copied "tcp" header. */
+ struct tcphdr *uh = (struct tcphdr *)(buf + eh_len + ih_len);
+
+ unsigned int jsum;
+
+ /* Copy the header. */
+ memcpy(buf, data, sh_len);
+
+ /* The packet size, not including ethernet header. */
+ jh->tot_len = htons(s_len - eh_len);
+
+ /* Update the ip "id". */
+ jh->id = htons(id);
+
+ /* Compute the "ip checksum". */
+ jsum = isum_hack + htons(s_len - eh_len) + htons(id);
+ jh->check = csum_long(jsum) ^ 0xffff;
+
+ /* Update the tcp "seq". */
+ uh->seq = htonl(seq);
+
+ /* Update some flags. */
+ if (!final) {
+ uh->fin = 0;
+ uh->psh = 0;
+ }
+
+ /* Compute the tcp pseudo-header checksum. */
+ uh->check = csum_long(tsum_hack + htons(s_len));
+
+ /* Skip past the header. */
+ slot++;
+
+ /* Skip past the payload. */
+ while (p_used < p_len) {
+
+ /* Advance as needed. */
+ while (f_used >= f_size) {
+ f_id++;
+ f_size = sh->frags[f_id].size;
+ f_used = 0;
+ }
+
+ /* Use bytes from the current fragment. */
+ n = p_len - p_used;
+ if (n > f_size - f_used)
+ n = f_size - f_used;
+ f_used += n;
+ p_used += n;
+
+ slot++;
+ }
+
+ id++;
+ seq += p_len;
+ }
+
+ /* Reset "slot". */
+ slot -= num_edescs;
+
+ /* Flush the headers. */
+ wmb();
+
+ /* Reset. */
+ f_id = -1;
+ f_size = -1;
+ f_used = -1;
+
+ /* Egress all the edescs. */
+ for (segment = 0; segment < sh->gso_segs; segment++) {
+
+ /* Detect the final segment. */
+ bool final = (segment == sh->gso_segs - 1);
+
+ /* The segment size (including header). */
+ unsigned int s_len = final ? mtu2 : mtu;
+
+ /* The size of the payload. */
+ unsigned int p_len = s_len - sh_len;
+
+ /* The bytes used from the payload. */
+ unsigned int p_used = 0;
+
+ /* Access the header memory for this segment. */
+ unsigned int bn = slot % EQUEUE_ENTRIES;
+ unsigned char *buf =
+ egress->headers + bn * HEADER_BYTES + NET_IP_ALIGN;
+
+ void *va;
+
+ /* Egress the header. */
+ edesc_head.va = va_to_tile_io_addr(buf);
+ gxio_mpipe_equeue_put_at(equeue, edesc_head, slot);
+ slot++;
+
+ /* Egress the payload. */
+ while (p_used < p_len) {
+
+ /* Advance as needed. */
+ while (f_used >= f_size) {
+ f_id++;
+ f_size = sh->frags[f_id].size;
+ f_used = 0;
+ }
+
+ va = tile_net_frag_buf(&sh->frags[f_id]) + f_used;
+
+ /* Use bytes from the current fragment. */
+ n = p_len - p_used;
+ if (n > f_size - f_used)
+ n = f_size - f_used;
+ f_used += n;
+ p_used += n;
+
+ /* Egress a piece of the payload. */
+ edesc_body.va = va_to_tile_io_addr(va);
+ edesc_body.xfer_size = n;
+ edesc_body.bound = !(p_used < p_len);
+ gxio_mpipe_equeue_put_at(equeue, edesc_body, slot);
+ slot++;
+ }
+
+ tx_packets++;
+ tx_bytes += s_len;
+ }
+
+ /* Add a completion record. */
+ add_comp(equeue, comps, slot - 1, skb);
+
+ /* Update stats. */
+ tile_net_stats_add(tx_packets, &priv->stats.tx_packets);
+ tile_net_stats_add(tx_bytes, &priv->stats.tx_bytes);
+
+ local_irq_restore(irqflags);
+
+ /* Make sure the egress timer is scheduled. */
+ tile_net_schedule_egress_timer(info);
+
+ return NETDEV_TX_OK;
+}
+
+/* Analyze the body and frags for a transmit request. */
+static unsigned int tile_net_tx_frags(struct frag *frags,
+ struct sk_buff *skb,
+ void *b_data, unsigned int b_len)
+{
+ unsigned int i, n = 0;
+
+ struct skb_shared_info *sh = skb_shinfo(skb);
+
+ if (b_len != 0) {
+ frags[n].buf = b_data;
+ frags[n++].length = b_len;
+ }
+
+ for (i = 0; i < sh->nr_frags; i++) {
+ skb_frag_t *f = &sh->frags[i];
+ frags[n].buf = tile_net_frag_buf(f);
+ frags[n++].length = skb_frag_size(f);
+ }
+
+ return n;
+}
+
+/* Help the kernel transmit a packet. */
+static int tile_net_tx(struct sk_buff *skb, struct net_device *dev)
+{
+ struct tile_net_priv *priv = netdev_priv(dev);
+ struct tile_net_info *info = &__get_cpu_var(per_cpu_info);
+ struct tile_net_egress *egress = &egress_for_echannel[priv->echannel];
+ gxio_mpipe_equeue_t *equeue = egress->equeue;
+ struct tile_net_comps *comps =
+ info->comps_for_echannel[priv->echannel];
+ struct skb_shared_info *sh = skb_shinfo(skb);
+ unsigned int len = skb->len;
+ unsigned char *data = skb->data;
+ unsigned int num_frags;
+ struct frag frags[MAX_FRAGS];
+ gxio_mpipe_edesc_t edescs[MAX_FRAGS];
+ unsigned long irqflags;
+ gxio_mpipe_edesc_t edesc = { { 0 } };
+ unsigned int i;
+ s64 slot;
+
+ /* Save the timestamp. */
+ dev->trans_start = jiffies;
+
+ if (sh->gso_size != 0)
+ return tile_net_tx_tso(skb, dev);
+
+ /* NOTE: This is usually 2, sometimes 3, for big writes. */
+ num_frags = tile_net_tx_frags(frags, skb, data, skb_headlen(skb));
+
+ /* This is only used to specify the TLB. */
+ edesc.stack_idx = large_buffer_stack;
+
+ /* Prepare the edescs. */
+ for (i = 0; i < num_frags; i++) {
+ edesc.xfer_size = frags[i].length;
+ edesc.va = va_to_tile_io_addr(frags[i].buf);
+ edescs[i] = edesc;
+ }
+
+ /* Mark the final edesc. */
+ edescs[num_frags - 1].bound = 1;
+
+ /* Add checksum info to the initial edesc, if needed. */
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ unsigned int csum_start = skb->csum_start - skb_headroom(skb);
+ edescs[0].csum = 1;
+ edescs[0].csum_start = csum_start;
+ edescs[0].csum_dest = csum_start + skb->csum_offset;
+ }
+
+ local_irq_save(irqflags);
+
+ /* Try to reserve slots for egress. If we fail due to the
+ * queue being full, we return NETDEV_TX_BUSY. This may lead
+ * to "Virtual device xxx asks to queue packet" warnings.
+ *
+ * We might consider retrying briefly here since We expect in
+ * principle that egress slots become available quickly as the
+ * hardware engine drains packets into the network.
+ *
+ * FIXME (bug# 9593): We should stop queues when they're full.
+ * We may want to consider making tile_net be multiqueue with
+ * one TX queue per CPU and ndo_select_queue defined
+ * accordingly. Initially we saw bad things happen when
+ * stopping the queue, so we are continuing to work on this
+ * for a future fix.
+ */
+ slot = gxio_mpipe_equeue_try_reserve(equeue, num_frags);
+ if (slot < 0) {
+ local_irq_restore(irqflags);
+ return NETDEV_TX_BUSY;
+ }
+
+ for (i = 0; i < num_frags; i++)
+ gxio_mpipe_equeue_put_at(equeue, edescs[i], slot++);
+
+ /* Add a completion record. */
+ add_comp(equeue, comps, slot - 1, skb);
+
+ /* HACK: Track "expanded" size for short packets (e.g. 42 < 60). */
+ tile_net_stats_add(1, &priv->stats.tx_packets);
+ tile_net_stats_add((len >= ETH_ZLEN) ? len : ETH_ZLEN,
+ &priv->stats.tx_bytes);
+
+ local_irq_restore(irqflags);
+
+ /* Make sure the egress timer is scheduled. */
+ tile_net_schedule_egress_timer(info);
+
+ return NETDEV_TX_OK;
+}
+
+/* Deal with a transmit timeout. */
+static void tile_net_tx_timeout(struct net_device *dev)
+{
+ /* ISSUE: This doesn't seem useful for us. */
+ netif_wake_queue(dev);
+}
+
+/* Ioctl commands. */
+static int tile_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+{
+ return -EOPNOTSUPP;
+}
+
+/* Get system network statistics for device. */
+static struct net_device_stats *tile_net_get_stats(struct net_device *dev)
+{
+ struct tile_net_priv *priv = netdev_priv(dev);
+ return &priv->stats;
+}
+
+/* Change the MTU. */
+static int tile_net_change_mtu(struct net_device *dev, int new_mtu)
+{
+ /* Check ranges. */
+ if ((new_mtu < 68) || (new_mtu > 1500))
+ return -EINVAL;
+
+ /* Accept the value. */
+ dev->mtu = new_mtu;
+
+ return 0;
+}
+
+/* Change the Ethernet address of the NIC.
+ *
+ * The hypervisor driver does not support changing MAC address. However,
+ * the hardware does not do anything with the MAC address, so the address
+ * which gets used on outgoing packets, and which is accepted on incoming
+ * packets, is completely up to us.
+ *
+ * Returns 0 on success, negative on failure.
+ */
+static int tile_net_set_mac_address(struct net_device *dev, void *p)
+{
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EINVAL;
+
+ memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
+
+ return 0;
+}
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/* Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void tile_net_netpoll(struct net_device *dev)
+{
+ disable_percpu_irq(ingress_irq);
+ tile_net_handle_ingress_irq(ingress_irq, NULL);
+ enable_percpu_irq(ingress_irq, 0);
+}
+#endif
+
+static const struct net_device_ops tile_net_ops = {
+ .ndo_open = tile_net_open,
+ .ndo_stop = tile_net_stop,
+ .ndo_start_xmit = tile_net_tx,
+ .ndo_do_ioctl = tile_net_ioctl,
+ .ndo_get_stats = tile_net_get_stats,
+ .ndo_change_mtu = tile_net_change_mtu,
+ .ndo_tx_timeout = tile_net_tx_timeout,
+ .ndo_set_mac_address = tile_net_set_mac_address,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = tile_net_netpoll,
+#endif
+};
+
+/* The setup function.
+ *
+ * This uses ether_setup() to assign various fields in dev, including
+ * setting IFF_BROADCAST and IFF_MULTICAST, then sets some extra fields.
+ */
+static void tile_net_setup(struct net_device *dev)
+{
+ ether_setup(dev);
+
+ dev->netdev_ops = &tile_net_ops;
+ dev->watchdog_timeo = TILE_NET_TIMEOUT;
+
+ /* We want lockless xmit. */
+ dev->features |= NETIF_F_LLTX;
+
+ /* We support hardware tx checksums. */
+ dev->features |= NETIF_F_HW_CSUM;
+
+ /* We support scatter/gather. */
+ dev->features |= NETIF_F_SG;
+
+ /* We support TSO. */
+ dev->features |= NETIF_F_TSO;
+
+ dev->tx_queue_len = 0;
+
+ dev->mtu = 1500;
+}
+
+/* Allocate the device structure, register the device, and obtain the
+ * MAC address from the hypervisor.
+ */
+static void tile_net_dev_init(const char *name, const uint8_t *mac)
+{
+ int ret;
+ int i;
+ int nz_addr = 0;
+ struct net_device *dev;
+ struct tile_net_priv *priv;
+
+ /* HACK: Ignore "loop" links. */
+ if (strncmp(name, "loop", 4) == 0)
+ return;
+
+ /* Allocate the device structure. This allocates "priv", calls
+ * tile_net_setup(), and saves "name". Normally, "name" is a
+ * template, instantiated by register_netdev(), but not for us.
+ */
+ dev = alloc_netdev(sizeof(*priv), name, tile_net_setup);
+ if (!dev) {
+ pr_err("alloc_netdev(%s) failed\n", name);
+ return;
+ }
+
+ priv = netdev_priv(dev);
+
+ /* Initialize "priv". */
+
+ memset(priv, 0, sizeof(*priv));
+
+ priv->dev = dev;
+
+ priv->channel = -1;
+ priv->loopify_channel = -1;
+ priv->echannel = -1;
+
+ /* Get the MAC address and set it in the device struct; this must
+ * be done before the device is opened. If the MAC is all zeroes,
+ * we use a random address, since we're probably on the simulator.
+ */
+ for (i = 0; i < 6; i++)
+ nz_addr |= mac[i];
+
+ if (nz_addr) {
+ memcpy(dev->dev_addr, mac, 6);
+ dev->addr_len = 6;
+ } else {
+ random_ether_addr(dev->dev_addr);
+ }
+
+ /* Register the network device. */
+ ret = register_netdev(dev);
+ if (ret) {
+ netdev_err(dev, "register_netdev failed %d\n", ret);
+ free_netdev(dev);
+ return;
+ }
+}
+
+/* Module initialization. */
+static int __init tile_net_init_module(void)
+{
+ int i;
+ char name[GXIO_MPIPE_LINK_NAME_LEN];
+ uint8_t mac[6];
+
+ pr_info("Tilera Network Driver\n");
+
+ mutex_init(&tile_net_devs_for_channel_mutex);
+
+ /* Initialize each CPU. */
+ on_each_cpu(tile_net_prepare_cpu, NULL, 1);
+
+ /* Find out what devices we have, and initialize them. */
+ for (i = 0; gxio_mpipe_link_enumerate_mac(i, name, mac) >= 0; i++)
+ tile_net_dev_init(name, mac);
+
+ if (!network_cpus_init())
+ network_cpus_map = *cpu_online_mask;
+
+ return 0;
+}
+
+module_init(tile_net_init_module);
--
1.6.5.2
^ permalink raw reply related
* [PATCH] net/ipv4: replace simple_strtoul with kstrtoul
From: Eldad Zack @ 2012-05-20 0:13 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel, Eldad Zack
Replace simple_strtoul with kstrtoul in three similar occurrences, all setup
handlers:
* route.c: set_rhash_entries
* tcp.c: set_thash_entries
* udp.c: set_uhash_entries
Also check if the conversion failed.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
---
net/ipv4/route.c | 8 +++++++-
net/ipv4/tcp.c | 8 +++++++-
net/ipv4/udp.c | 8 +++++++-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 167ea10..84d1832 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -3430,9 +3430,15 @@ struct ip_rt_acct __percpu *ip_rt_acct __read_mostly;
static __initdata unsigned long rhash_entries;
static int __init set_rhash_entries(char *str)
{
+ ssize_t ret;
+
if (!str)
return 0;
- rhash_entries = simple_strtoul(str, &str, 0);
+
+ ret = kstrtoul(str, 0, &rhash_entries);
+ if (ret)
+ return 0;
+
return 1;
}
__setup("rhash_entries=", set_rhash_entries);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 6589e11..6ed0552 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3222,9 +3222,15 @@ extern struct tcp_congestion_ops tcp_reno;
static __initdata unsigned long thash_entries;
static int __init set_thash_entries(char *str)
{
+ ssize_t ret;
+
if (!str)
return 0;
- thash_entries = simple_strtoul(str, &str, 0);
+
+ ret = kstrtoul(str, 0, &thash_entries);
+ if (ret)
+ return 0;
+
return 1;
}
__setup("thash_entries=", set_thash_entries);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index fe14105..662836a 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2163,9 +2163,15 @@ void udp4_proc_exit(void)
static __initdata unsigned long uhash_entries;
static int __init set_uhash_entries(char *str)
{
+ ssize_t ret;
+
if (!str)
return 0;
- uhash_entries = simple_strtoul(str, &str, 0);
+
+ ret = kstrtoul(str, 0, &uhash_entries);
+ if (ret)
+ return 0;
+
if (uhash_entries && uhash_entries < UDP_HTABLE_SIZE_MIN)
uhash_entries = UDP_HTABLE_SIZE_MIN;
return 1;
--
1.7.10
^ permalink raw reply related
* [PATCH] net/ipv4/ipconfig: neaten __setup placement
From: Eldad Zack @ 2012-05-20 0:04 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel, Eldad Zack
The __setup macro should follow the corresponding setup handler.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
---
net/ipv4/ipconfig.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 92ac7e7..1d8076a 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1626,11 +1626,13 @@ static int __init ip_auto_config_setup(char *addrs)
return 1;
}
+__setup("ip=", ip_auto_config_setup);
static int __init nfsaddrs_config_setup(char *addrs)
{
return ip_auto_config_setup(addrs);
}
+__setup("nfsaddrs=", nfsaddrs_config_setup);
static int __init vendor_class_identifier_setup(char *addrs)
{
@@ -1641,7 +1643,4 @@ static int __init vendor_class_identifier_setup(char *addrs)
vendor_class_identifier);
return 1;
}
-
-__setup("ip=", ip_auto_config_setup);
-__setup("nfsaddrs=", nfsaddrs_config_setup);
__setup("dhcpclass=", vendor_class_identifier_setup);
--
1.7.10
^ permalink raw reply related
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