* Re: Stable regression with 'tcp: allow splice() to build full TSO packets'
From: Eric Dumazet @ 2012-05-17 16:47 UTC (permalink / raw)
To: Willy Tarreau; +Cc: netdev
In-Reply-To: <20120517164016.GL14498@1wt.eu>
On Thu, 2012-05-17 at 18:40 +0200, Willy Tarreau wrote:
> On Thu, May 17, 2012 at 06:33:24PM +0200, Eric Dumazet wrote:
> > On Thu, 2012-05-17 at 17:56 +0200, Willy Tarreau wrote:
> > > On Thu, May 17, 2012 at 05:43:00PM +0200, Eric Dumazet wrote:
> >
> > > It's the NIC included in the system-on-chip (Marvell 88F6281), and the NIC
> > > driver is mv643xx. It's the same hardware you find in sheevaplugs, guruplugs,
> > > dreamplugs and almost all ARM-based cheap NAS boxes.
> > >
> > > > With commit 1d0c0b328a6 in net-next
> > > > (net: makes skb_splice_bits() aware of skb->head_frag)
> > > > You'll be able to get even more speed, if NIC uses frag to hold frame.
> > >
> > > I'm going to check this now, sounds interesting :-)
> >
> > splice(socket -> pipe) does a copy of frame from skb->head to a page
> > fragment.
> >
> > With latest patches (net-next), we can provide a frag for skb->head and
> > avoid this copy in splice(). You would have a true zero copy
> > socket->socket mode.
>
> That's what I've read in your commit messages. Indeed, we've been waiting
> for this to happen for a long time. It should bring a real benefit on small
> devices like the one I'm playing with which have very low memory bandwidth,
> because it's a shame to copy the data and thrash the cache when we don't
> need to see them.
>
> I'm currently trying to get mainline to boot then I'll switch to net-next.
>
> > tg3 drivers uses this new thing, mv643xx_eth.c could be changed as well.
>
> I'll try to port your patch (8d4057 tg3: provide frags as skb head) to
> mv643xx_eth as an exercise. If I succeed and notice an improvement, I'll
> send a patch :-)
In fact I could post a generic patch, to make netdev_alloc_skb() do this
automatically for all network drivers.
Its probably less than 30 lines of code.
^ permalink raw reply
* Re: Stable regression with 'tcp: allow splice() to build full TSO packets'
From: Eric Dumazet @ 2012-05-17 16:49 UTC (permalink / raw)
To: Willy Tarreau; +Cc: netdev
In-Reply-To: <20120517164016.GL14498@1wt.eu>
On Thu, 2012-05-17 at 18:40 +0200, Willy Tarreau wrote:
> try to port your patch (8d4057 tg3: provide frags as skb head) to
> mv643xx_eth as an exercise. If I succeed and notice an improvement, I'll
> send a patch :-)
tg3 uses build_skb(), thats an API that allocates the skb after frame is
filled by the device, to have less cache misses in RX path.
But for most devices, netdev_alloc_skb() would be more than enough.
I'll send a patch once tested.
Thanks
^ permalink raw reply
* Re: [PATCH 2/5] drivers/net: delete all code/drivers depending on CONFIG_MCA
From: Paul Gortmaker @ 2012-05-17 16:51 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-kernel, JBottomley, David S. Miller, netdev
In-Reply-To: <1337272841-25931-3-git-send-email-paul.gortmaker@windriver.com>
On 12-05-17 12:40 PM, Paul Gortmaker wrote:
[..]
> 18 files changed, 18 insertions(+), 5288 deletions(-)
> delete mode 100644 drivers/net/ethernet/8390/ne2.c
> delete mode 100644 drivers/net/ethernet/8390/smc-mca.c
> delete mode 100644 drivers/net/ethernet/i825xx/3c523.c
> delete mode 100644 drivers/net/ethernet/i825xx/3c523.h
> delete mode 100644 drivers/net/ethernet/i825xx/3c527.c
I can also obviously delete 3c527.h too. Not sure why I didn't
notice that until just now... :(
Paul.
---
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Denys Fedoryshchenko @ 2012-05-17 16:54 UTC (permalink / raw)
To: netdev, e1000-devel, jeffrey.t.kirsher, jesse.brandeburg,
therbert, eric.dumazet, davem
In-Reply-To: <88c43001441945e1431609db252b69e7@visp.net.lb>
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
^ permalink raw reply
* Re: [PATCH v5 2/2] decrement static keys on real destroy time
From: Andrew Morton @ 2012-05-17 17:02 UTC (permalink / raw)
To: Glauber Costa
Cc: cgroups, linux-mm, devel, kamezawa.hiroyu, netdev, Tejun Heo,
Li Zefan, Johannes Weiner, Michal Hocko
In-Reply-To: <4FB4CA4D.50608@parallels.com>
On Thu, 17 May 2012 13:52:13 +0400 Glauber Costa <glommer@parallels.com> wrote:
> Andrew is right. It seems we will need that mutex after all. Just this
> is not a race, and neither something that should belong in the
> static_branch interface.
Well, a mutex is one way. Or you could do something like
if (!test_and_set_bit(CGPROTO_ACTIVATED, &cg_proto->flags))
static_key_slow_inc(&memcg_socket_limit_enabled);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC 13/13] USB: Disable hub-initiated LPM for comms devices.
From: Tilman Schmidt @ 2012-05-17 17:07 UTC (permalink / raw)
To: Sarah Sharp
Cc: Greg Kroah-Hartman, linux-usb-u79uwXL29TY76Z2rM5mHXA, Alan Stern,
Hansjoerg Lipp, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
gigaset307x-common-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H
In-Reply-To: <3c634afbbe15598cdcbf77bb9393d22ad4bfa373.1337203535.git.sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
Am 16.05.2012 23:55, schrieb Sarah Sharp:
> Set the disable_hub_initiated_lpm flag for for all USB communications
> drivers. I know there aren't currently any USB 3.0 devices that
> implement these class specifications, but we should be ready if they do.
I follow the argument for class drivers. But this patch also
modifies drivers for specific existing USB 2.0 only devices
which are unlikely to ever grow USB 3.0 support, such as the
Gigaset ISDN driver:
> drivers/isdn/gigaset/bas-gigaset.c | 1 +
> drivers/isdn/gigaset/usb-gigaset.c | 1 +
What is the interest of setting the disable_hub_initiated_lpm
flag for these?
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman-ZTO5kqT2PaM@public.gmane.org
Bonn, Germany
In theory there is no difference between theory and practice.
In practice there is. (Yogi Berra)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [PATCH V3] CS89x0 : Use ioread16/iowrite16 on all platforms
From: Jaccon Bastiaansen @ 2012-05-17 17:11 UTC (permalink / raw)
To: arnd
Cc: joe, romieu, s.hauer, gfm, davem, festevam, linux-arm-kernel,
netdev, Jaccon Bastiaansen
The use of the inw/outw functions by the cs89x0 platform driver
results in NULL pointer references on ARM platforms and
platforms that do not provide ISA-style programmed I/O accessors.
Using inw/outw also accesses the wrong address space on platforms
that have a PCI I/O space that is not identity-mapped into the
physical address space.
Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
---
drivers/net/ethernet/cirrus/cs89x0.c | 341 ++++++++++++++++++----------------
1 files changed, 183 insertions(+), 158 deletions(-)
diff --git a/drivers/net/ethernet/cirrus/cs89x0.c b/drivers/net/ethernet/cirrus/cs89x0.c
index b9406cb..1d59030 100644
--- a/drivers/net/ethernet/cirrus/cs89x0.c
+++ b/drivers/net/ethernet/cirrus/cs89x0.c
@@ -222,6 +222,8 @@ struct net_local {
int send_underrun; /* keep track of how many underruns in a row we get */
int force; /* force various values; see FORCE* above. */
spinlock_t lock;
+ void __iomem *virt_addr;/* CS89x0 virtual address. */
+ unsigned long size; /* Length of CS89x0 memory region. */
#if ALLOW_DMA
int use_dma; /* Flag: we're using dma */
int dma; /* DMA channel */
@@ -230,16 +232,9 @@ struct net_local {
unsigned char *end_dma_buff; /* points to the end of the buffer */
unsigned char *rx_dma_ptr; /* points to the next packet */
#endif
-#ifdef CONFIG_CS89x0_PLATFORM
- void __iomem *virt_addr;/* Virtual address for accessing the CS89x0. */
- unsigned long phys_addr;/* Physical address for accessing the CS89x0. */
- unsigned long size; /* Length of CS89x0 memory region. */
-#endif
};
/* Index to functions, as function prototypes. */
-
-static int cs89x0_probe1(struct net_device *dev, unsigned long ioaddr, int modular);
static int net_open(struct net_device *dev);
static netdev_tx_t net_send_packet(struct sk_buff *skb, struct net_device *dev);
static irqreturn_t net_interrupt(int irq, void *dev_id);
@@ -267,7 +262,8 @@ static void release_dma_buff(struct net_local *lp);
/*
* Permit 'cs89x0_dma=N' in the kernel boot environment
*/
-#if !defined(MODULE) && (ALLOW_DMA != 0)
+#if !defined(MODULE)
+#if ALLOW_DMA
static int g_cs89x0_dma;
static int __init dma_fn(char *str)
@@ -277,9 +273,8 @@ static int __init dma_fn(char *str)
}
__setup("cs89x0_dma=", dma_fn);
-#endif /* !defined(MODULE) && (ALLOW_DMA != 0) */
+#endif /* ALLOW_DMA */
-#ifndef MODULE
static int g_cs89x0_media__force;
static int __init media_fn(char *str)
@@ -291,58 +286,6 @@ static int __init media_fn(char *str)
}
__setup("cs89x0_media=", media_fn);
-
-
-#ifndef CONFIG_CS89x0_PLATFORM
-/* Check for a network adaptor of this type, and return '0' iff one exists.
- If dev->base_addr == 0, probe all likely locations.
- If dev->base_addr == 1, always return failure.
- If dev->base_addr == 2, allocate space for the device and return success
- (detachable devices only).
- Return 0 on success.
- */
-
-struct net_device * __init cs89x0_probe(int unit)
-{
- struct net_device *dev = alloc_etherdev(sizeof(struct net_local));
- unsigned *port;
- int err = 0;
- int irq;
- int io;
-
- if (!dev)
- return ERR_PTR(-ENODEV);
-
- sprintf(dev->name, "eth%d", unit);
- netdev_boot_setup_check(dev);
- io = dev->base_addr;
- irq = dev->irq;
-
- if (net_debug)
- printk("cs89x0:cs89x0_probe(0x%x)\n", io);
-
- if (io > 0x1ff) { /* Check a single specified location. */
- err = cs89x0_probe1(dev, io, 0);
- } else if (io != 0) { /* Don't probe at all. */
- err = -ENXIO;
- } else {
- for (port = netcard_portlist; *port; port++) {
- if (cs89x0_probe1(dev, *port, 0) == 0)
- break;
- dev->irq = irq;
- }
- if (!*port)
- err = -ENODEV;
- }
- if (err)
- goto out;
- return dev;
-out:
- free_netdev(dev);
- printk(KERN_WARNING "cs89x0: no cs8900 or cs8920 detected. Be sure to disable PnP with SETUP\n");
- return ERR_PTR(err);
-}
-#endif
#endif
#if defined(CONFIG_MACH_IXDP2351)
@@ -369,36 +312,22 @@ writeword(unsigned long base_addr, int portno, u16 value)
{
__raw_writel(value, base_addr + (portno << 1));
}
-#else
-static u16
-readword(unsigned long base_addr, int portno)
-{
- return inw(base_addr + portno);
-}
-
-static void
-writeword(unsigned long base_addr, int portno, u16 value)
-{
- outw(value, base_addr + portno);
-}
#endif
-static void
-readwords(unsigned long base_addr, int portno, void *buf, int length)
+static void readwords(struct net_local *lp, int portno, void *buf, int length)
{
u8 *buf8 = (u8 *)buf;
do {
u16 tmp16;
- tmp16 = readword(base_addr, portno);
+ tmp16 = ioread16(lp->virt_addr + portno);
*buf8++ = (u8)tmp16;
*buf8++ = (u8)(tmp16 >> 8);
} while (--length);
}
-static void
-writewords(unsigned long base_addr, int portno, void *buf, int length)
+static void writewords(struct net_local *lp, int portno, void *buf, int length)
{
u8 *buf8 = (u8 *)buf;
@@ -407,22 +336,26 @@ writewords(unsigned long base_addr, int portno, void *buf, int length)
tmp16 = *buf8++;
tmp16 |= (*buf8++) << 8;
- writeword(base_addr, portno, tmp16);
+ iowrite16(tmp16, lp->virt_addr + portno);
} while (--length);
}
static u16
readreg(struct net_device *dev, u16 regno)
{
- writeword(dev->base_addr, ADD_PORT, regno);
- return readword(dev->base_addr, DATA_PORT);
+ struct net_local *lp = netdev_priv(dev);
+
+ iowrite16(regno, lp->virt_addr + ADD_PORT);
+ return ioread16(lp->virt_addr + DATA_PORT);
}
static void
writereg(struct net_device *dev, u16 regno, u16 value)
{
- writeword(dev->base_addr, ADD_PORT, regno);
- writeword(dev->base_addr, DATA_PORT, value);
+ struct net_local *lp = netdev_priv(dev);
+
+ iowrite16(regno, lp->virt_addr + ADD_PORT);
+ iowrite16(value, lp->virt_addr + DATA_PORT);
}
static int __init
@@ -505,7 +438,7 @@ static const struct net_device_ops net_ops = {
*/
static int __init
-cs89x0_probe1(struct net_device *dev, unsigned long ioaddr, int modular)
+cs89x0_probe1(struct net_device *dev, void __iomem *ioaddr, int modular)
{
struct net_local *lp = netdev_priv(dev);
static unsigned version_printed;
@@ -529,50 +462,22 @@ cs89x0_probe1(struct net_device *dev, unsigned long ioaddr, int modular)
#endif
lp->force = g_cs89x0_media__force;
#endif
-
}
- /* Grab the region so we can find another board if autoIRQ fails. */
- /* WTF is going on here? */
- if (!request_region(ioaddr & ~3, NETCARD_IO_EXTENT, DRV_NAME)) {
- printk(KERN_ERR "%s: request_region(0x%lx, 0x%x) failed\n",
- DRV_NAME, ioaddr, NETCARD_IO_EXTENT);
- retval = -EBUSY;
- goto out1;
- }
+ printk(KERN_DEBUG "PP_addr at %p[%x]: 0x%x\n",
+ ioaddr, ADD_PORT, ioread16(ioaddr + ADD_PORT));
+ iowrite16(PP_ChipID, ioaddr + ADD_PORT);
- /* if they give us an odd I/O address, then do ONE write to
- the address port, to get it back to address zero, where we
- expect to find the EISA signature word. An IO with a base of 0x3
- will skip the test for the ADD_PORT. */
- if (ioaddr & 1) {
- if (net_debug > 1)
- printk(KERN_INFO "%s: odd ioaddr 0x%lx\n", dev->name, ioaddr);
- if ((ioaddr & 2) != 2)
- if ((readword(ioaddr & ~3, ADD_PORT) & ADD_MASK) != ADD_SIG) {
- printk(KERN_ERR "%s: bad signature 0x%x\n",
- dev->name, readword(ioaddr & ~3, ADD_PORT));
- retval = -ENODEV;
- goto out2;
- }
- }
-
- ioaddr &= ~3;
- printk(KERN_DEBUG "PP_addr at %lx[%x]: 0x%x\n",
- ioaddr, ADD_PORT, readword(ioaddr, ADD_PORT));
- writeword(ioaddr, ADD_PORT, PP_ChipID);
-
- tmp = readword(ioaddr, DATA_PORT);
+ tmp = ioread16(ioaddr + DATA_PORT);
if (tmp != CHIP_EISA_ID_SIG) {
- printk(KERN_DEBUG "%s: incorrect signature at %lx[%x]: 0x%x!="
+ printk(KERN_DEBUG "%s: incorrect signature at %p[%x]: 0x%x!="
CHIP_EISA_ID_SIG_STR "\n",
dev->name, ioaddr, DATA_PORT, tmp);
retval = -ENODEV;
- goto out2;
+ goto out1;
}
- /* Fill in the 'dev' fields. */
- dev->base_addr = ioaddr;
+ lp->virt_addr = ioaddr;
/* get the chip type */
rev_type = readreg(dev, PRODUCT_ID_ADD);
@@ -590,12 +495,12 @@ cs89x0_probe1(struct net_device *dev, unsigned long ioaddr, int modular)
if (net_debug && version_printed++ == 0)
printk(version);
- printk(KERN_INFO "%s: cs89%c0%s rev %c found at %#3lx ",
+ printk(KERN_INFO "%s: cs89%c0%s rev %c found at %p ",
dev->name,
lp->chip_type==CS8900?'0':'2',
lp->chip_type==CS8920M?"M":"",
lp->chip_revision,
- dev->base_addr);
+ lp->virt_addr);
reset_chip(dev);
@@ -787,16 +692,125 @@ cs89x0_probe1(struct net_device *dev, unsigned long ioaddr, int modular)
retval = register_netdev(dev);
if (retval)
- goto out3;
+ goto out2;
return 0;
-out3:
- writeword(dev->base_addr, ADD_PORT, PP_ChipID);
out2:
- release_region(ioaddr & ~3, NETCARD_IO_EXTENT);
+ iowrite16(PP_ChipID, lp->virt_addr + ADD_PORT);
out1:
return retval;
}
+#ifndef CONFIG_CS89x0_PLATFORM
+/*
+ * This function converts the I/O port addres used by the cs89x0_probe() and
+ * init_module() functions to the I/O memory address used by the
+ * cs89x0_probe1() function.
+ */
+static int __init
+cs89x0_ioport_probe(struct net_device *dev, unsigned long ioport, int modular)
+{
+ struct net_local *lp = netdev_priv(dev);
+ int ret;
+ void __iomem *io_mem;
+
+ if (!lp)
+ return -ENOMEM;
+
+ dev->base_addr = ioport;
+
+ if (!request_region(ioport, NETCARD_IO_EXTENT, DRV_NAME)) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ io_mem = ioport_map(ioport & ~3, NETCARD_IO_EXTENT);
+ if (!io_mem) {
+ ret = -ENOMEM;
+ goto release;
+ }
+
+ /* if they give us an odd I/O address, then do ONE write to
+ the address port, to get it back to address zero, where we
+ expect to find the EISA signature word. An IO with a base of 0x3
+ will skip the test for the ADD_PORT. */
+ if (ioport & 1) {
+ if (net_debug > 1)
+ printk(KERN_INFO "%s: odd ioaddr 0x%lx\n",
+ dev->name,
+ ioport);
+ if ((ioport & 2) != 2)
+ if ((ioread16(io_mem + ADD_PORT) & ADD_MASK) !=
+ ADD_SIG) {
+ printk(KERN_ERR "%s: bad signature 0x%x\n",
+ dev->name,
+ ioread16(io_mem + ADD_PORT));
+ ret = -ENODEV;
+ goto unmap;
+ }
+ }
+
+ ret = cs89x0_probe1(dev, io_mem, modular);
+ if (!ret)
+ goto out;
+unmap:
+ ioport_unmap(io_mem);
+release:
+ release_region(ioport, NETCARD_IO_EXTENT);
+out:
+ return ret;
+}
+
+#ifndef MODULE
+/* Check for a network adaptor of this type, and return '0' iff one exists.
+ If dev->base_addr == 0, probe all likely locations.
+ If dev->base_addr == 1, always return failure.
+ If dev->base_addr == 2, allocate space for the device and return success
+ (detachable devices only).
+ Return 0 on success.
+ */
+
+struct net_device * __init cs89x0_probe(int unit)
+{
+ struct net_device *dev = alloc_etherdev(sizeof(struct net_local));
+ unsigned *port;
+ int err = 0;
+ int irq;
+ int io;
+
+ if (!dev)
+ return ERR_PTR(-ENODEV);
+
+ sprintf(dev->name, "eth%d", unit);
+ netdev_boot_setup_check(dev);
+ io = dev->base_addr;
+ irq = dev->irq;
+
+ if (net_debug)
+ printk(KERN_INFO "cs89x0:cs89x0_probe(0x%x)\n", io);
+
+ if (io > 0x1ff) { /* Check a single specified location. */
+ err = cs89x0_ioport_probe(dev, io, 0);
+ } else if (io != 0) { /* Don't probe at all. */
+ err = -ENXIO;
+ } else {
+ for (port = netcard_portlist; *port; port++) {
+ if (cs89x0_ioport_probe(dev, *port, 0) == 0)
+ break;
+ dev->irq = irq;
+ }
+ if (!*port)
+ err = -ENODEV;
+ }
+ if (err)
+ goto out;
+ return dev;
+out:
+ free_netdev(dev);
+ printk(KERN_WARNING "cs89x0: no cs8900 or cs8920 detected. Be sure to disable PnP with SETUP\n");
+ return ERR_PTR(err);
+}
+#endif
+#endif
/*********************************
* This page contains DMA routines
@@ -956,7 +970,6 @@ static void __init reset_chip(struct net_device *dev)
#if !defined(CONFIG_MACH_MX31ADS)
#if !defined(CS89x0_NONISA_IRQ)
struct net_local *lp = netdev_priv(dev);
- int ioaddr = dev->base_addr;
#endif /* CS89x0_NONISA_IRQ */
int reset_start_time;
@@ -968,13 +981,15 @@ static void __init reset_chip(struct net_device *dev)
#if !defined(CS89x0_NONISA_IRQ)
if (lp->chip_type != CS8900) {
/* Hardware problem requires PNP registers to be reconfigured after a reset */
- writeword(ioaddr, ADD_PORT, PP_CS8920_ISAINT);
- outb(dev->irq, ioaddr + DATA_PORT);
- outb(0, ioaddr + DATA_PORT + 1);
-
- writeword(ioaddr, ADD_PORT, PP_CS8920_ISAMemB);
- outb((dev->mem_start >> 16) & 0xff, ioaddr + DATA_PORT);
- outb((dev->mem_start >> 8) & 0xff, ioaddr + DATA_PORT + 1);
+ iowrite16(PP_CS8920_ISAINT, lp->virt_addr + ADD_PORT);
+ iowrite8(dev->irq, lp->virt_addr + DATA_PORT);
+ iowrite8(0, lp->virt_addr + DATA_PORT + 1);
+
+ iowrite16(PP_CS8920_ISAMemB, lp->virt_addr + ADD_PORT);
+ iowrite8((dev->mem_start >> 16) & 0xff,
+ lp->virt_addr + DATA_PORT);
+ iowrite8((dev->mem_start >> 8) & 0xff,
+ lp->virt_addr + DATA_PORT + 1);
}
#endif /* CS89x0_NONISA_IRQ */
@@ -1092,6 +1107,7 @@ detect_tp(struct net_device *dev)
static int
send_test_pkt(struct net_device *dev)
{
+ struct net_local *lp = netdev_priv(dev);
char test_packet[] = { 0,0,0,0,0,0, 0,0,0,0,0,0,
0, 46, /* A 46 in network order */
0, 0, /* DSAP=0 & SSAP=0 fields */
@@ -1103,8 +1119,8 @@ send_test_pkt(struct net_device *dev)
memcpy(test_packet, dev->dev_addr, ETH_ALEN);
memcpy(test_packet+ETH_ALEN, dev->dev_addr, ETH_ALEN);
- writeword(dev->base_addr, TX_CMD_PORT, TX_AFTER_ALL);
- writeword(dev->base_addr, TX_LEN_PORT, ETH_ZLEN);
+ iowrite16(TX_AFTER_ALL, lp->virt_addr + TX_CMD_PORT);
+ iowrite16(ETH_ZLEN, lp->virt_addr + TX_LEN_PORT);
/* Test to see if the chip has allocated memory for the packet */
while (jiffies - timenow < 5)
@@ -1114,7 +1130,7 @@ send_test_pkt(struct net_device *dev)
return 0; /* this shouldn't happen */
/* Write the contents of the packet */
- writewords(dev->base_addr, TX_FRAME_PORT,test_packet,(ETH_ZLEN+1) >>1);
+ writewords(lp, TX_FRAME_PORT, test_packet, (ETH_ZLEN+1) >> 1);
if (net_debug > 1) printk("Sending test packet ");
/* wait a couple of jiffies for packet to be received */
@@ -1458,8 +1474,8 @@ static netdev_tx_t net_send_packet(struct sk_buff *skb,struct net_device *dev)
netif_stop_queue(dev);
/* initiate a transmit sequence */
- writeword(dev->base_addr, TX_CMD_PORT, lp->send_cmd);
- writeword(dev->base_addr, TX_LEN_PORT, skb->len);
+ iowrite16(lp->send_cmd, lp->virt_addr + TX_CMD_PORT);
+ iowrite16(skb->len, lp->virt_addr + TX_LEN_PORT);
/* Test to see if the chip has allocated memory for the packet */
if ((readreg(dev, PP_BusST) & READY_FOR_TX_NOW) == 0) {
@@ -1473,7 +1489,7 @@ static netdev_tx_t net_send_packet(struct sk_buff *skb,struct net_device *dev)
return NETDEV_TX_BUSY;
}
/* Write the contents of the packet */
- writewords(dev->base_addr, TX_FRAME_PORT,skb->data,(skb->len+1) >>1);
+ writewords(lp, TX_FRAME_PORT, skb->data, (skb->len+1) >> 1);
spin_unlock_irqrestore(&lp->lock, flags);
dev->stats.tx_bytes += skb->len;
dev_kfree_skb (skb);
@@ -1499,10 +1515,9 @@ static irqreturn_t net_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct net_local *lp;
- int ioaddr, status;
+ int status;
int handled = 0;
- ioaddr = dev->base_addr;
lp = netdev_priv(dev);
/* we MUST read all the events out of the ISQ, otherwise we'll never
@@ -1512,7 +1527,7 @@ static irqreturn_t net_interrupt(int irq, void *dev_id)
course, if you're on a slow machine, and packets are arriving
faster than you can read them off, you're screwed. Hasta la
vista, baby! */
- while ((status = readword(dev->base_addr, ISQ_PORT))) {
+ while ((status = ioread16(lp->virt_addr + ISQ_PORT))) {
if (net_debug > 4)printk("%s: event=%04x\n", dev->name, status);
handled = 1;
switch(status & ISQ_EVENT_MASK) {
@@ -1608,12 +1623,12 @@ count_rx_errors(int status, struct net_device *dev)
static void
net_rx(struct net_device *dev)
{
+ struct net_local *lp = netdev_priv(dev);
struct sk_buff *skb;
int status, length;
- int ioaddr = dev->base_addr;
- status = readword(ioaddr, RX_FRAME_PORT);
- length = readword(ioaddr, RX_FRAME_PORT);
+ status = ioread16(lp->virt_addr + RX_FRAME_PORT);
+ length = ioread16(lp->virt_addr + RX_FRAME_PORT);
if ((status & RX_OK) == 0) {
count_rx_errors(status, dev);
@@ -1631,9 +1646,9 @@ net_rx(struct net_device *dev)
}
skb_reserve(skb, 2); /* longword align L3 header */
- readwords(ioaddr, RX_FRAME_PORT, skb_put(skb, length), length >> 1);
+ readwords(lp, RX_FRAME_PORT, skb_put(skb, length), length >> 1);
if (length & 1)
- skb->data[length-1] = readword(ioaddr, RX_FRAME_PORT);
+ skb->data[length-1] = ioread16(lp->virt_addr + RX_FRAME_PORT);
if (net_debug > 3) {
printk( "%s: received %d byte packet of type %x\n",
@@ -1886,7 +1901,7 @@ int __init init_module(void)
goto out;
}
#endif
- ret = cs89x0_probe1(dev, io, 1);
+ ret = cs89x0_ioport_probe(dev, io, 1);
if (ret)
goto out;
@@ -1900,8 +1915,11 @@ out:
void __exit
cleanup_module(void)
{
+ struct net_local *lp = netdev_priv(dev_cs89x0);
+
unregister_netdev(dev_cs89x0);
- writeword(dev_cs89x0->base_addr, ADD_PORT, PP_ChipID);
+ iowrite16(PP_ChipID, lp->virt_addr + ADD_PORT);
+ ioport_unmap(lp->virt_addr);
release_region(dev_cs89x0->base_addr, NETCARD_IO_EXTENT);
free_netdev(dev_cs89x0);
}
@@ -1913,6 +1931,7 @@ static int __init cs89x0_platform_probe(struct platform_device *pdev)
struct net_device *dev = alloc_etherdev(sizeof(struct net_local));
struct net_local *lp;
struct resource *mem_res;
+ void __iomem *virt_addr;
int err;
if (!dev)
@@ -1928,22 +1947,21 @@ static int __init cs89x0_platform_probe(struct platform_device *pdev)
goto free;
}
- lp->phys_addr = mem_res->start;
lp->size = resource_size(mem_res);
- if (!request_mem_region(lp->phys_addr, lp->size, DRV_NAME)) {
+ if (!request_mem_region(mem_res->start, lp->size, DRV_NAME)) {
dev_warn(&dev->dev, "request_mem_region() failed.\n");
err = -EBUSY;
goto free;
}
- lp->virt_addr = ioremap(lp->phys_addr, lp->size);
- if (!lp->virt_addr) {
+ virt_addr = ioremap(mem_res->start, lp->size);
+ if (!virt_addr) {
dev_warn(&dev->dev, "ioremap() failed.\n");
err = -ENOMEM;
goto release;
}
- err = cs89x0_probe1(dev, (unsigned long)lp->virt_addr, 0);
+ err = cs89x0_probe1(dev, virt_addr, 0);
if (err) {
dev_warn(&dev->dev, "no cs8900 or cs8920 detected.\n");
goto unmap;
@@ -1953,9 +1971,9 @@ static int __init cs89x0_platform_probe(struct platform_device *pdev)
return 0;
unmap:
- iounmap(lp->virt_addr);
+ iounmap(virt_addr);
release:
- release_mem_region(lp->phys_addr, lp->size);
+ release_mem_region(mem_res->start, lp->size);
free:
free_netdev(dev);
return err;
@@ -1965,10 +1983,17 @@ static int cs89x0_platform_remove(struct platform_device *pdev)
{
struct net_device *dev = platform_get_drvdata(pdev);
struct net_local *lp = netdev_priv(dev);
+ struct resource *mem_res;
+ /*
+ * This platform_get_resource() call will not return NULL, because
+ * the same call in cs89x0_platform_probe() has returned a non NULL
+ * value.
+ */
+ mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
unregister_netdev(dev);
iounmap(lp->virt_addr);
- release_mem_region(lp->phys_addr, lp->size);
+ release_mem_region(mem_res->start, lp->size);
free_netdev(dev);
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: Stable regression with 'tcp: allow splice() to build full TSO packets'
From: Willy Tarreau @ 2012-05-17 17:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1337273387.3403.24.camel@edumazet-glaptop>
On Thu, May 17, 2012 at 06:49:47PM +0200, Eric Dumazet wrote:
> On Thu, 2012-05-17 at 18:40 +0200, Willy Tarreau wrote:
> > try to port your patch (8d4057 tg3: provide frags as skb head) to
> > mv643xx_eth as an exercise. If I succeed and notice an improvement, I'll
> > send a patch :-)
>
>
> tg3 uses build_skb(), thats an API that allocates the skb after frame is
> filled by the device, to have less cache misses in RX path.
>
> But for most devices, netdev_alloc_skb() would be more than enough.
OK, so that's out of reach for me right now.
> I'll send a patch once tested.
I'll happily give it a try.
BTW, net-next gave me around 13-14% improvement over 3.0/3.2+splice
patches ! Now I'm seeing splice() being 75% faster than recv/send, while
it used to be slower on this hardware not that long ago! That's really
impressive, great work!
Willy
^ permalink raw reply
* Re: [RFC 13/13] USB: Disable hub-initiated LPM for comms devices.
From: Sarah Sharp @ 2012-05-17 17:31 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Greg Kroah-Hartman, linux-usb-u79uwXL29TY76Z2rM5mHXA, Alan Stern,
Hansjoerg Lipp, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
gigaset307x-common-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H
In-Reply-To: <4FB53054.9070309-ZTO5kqT2PaM@public.gmane.org>
On Thu, May 17, 2012 at 07:07:32PM +0200, Tilman Schmidt wrote:
> Am 16.05.2012 23:55, schrieb Sarah Sharp:
> > Set the disable_hub_initiated_lpm flag for for all USB communications
> > drivers. I know there aren't currently any USB 3.0 devices that
> > implement these class specifications, but we should be ready if they do.
>
> I follow the argument for class drivers. But this patch also
> modifies drivers for specific existing USB 2.0 only devices
> which are unlikely to ever grow USB 3.0 support, such as the
> Gigaset ISDN driver:
>
> > drivers/isdn/gigaset/bas-gigaset.c | 1 +
> > drivers/isdn/gigaset/usb-gigaset.c | 1 +
Is there a particular reason why you think that driver is unlikely to
ever get USB 3.0 support? I pretty much grabbed any USB driver that
looked like a communications driver without looking too closely at the
code.
> What is the interest of setting the disable_hub_initiated_lpm
> flag for these?
It's partially to lay the foundation for anyone who wants to make a USB
3.0 communications driver in the future. They're likely to start from
some USB 2.0 class driver, and copy a lot of code. If they notice that
flag is set in all the USB communications class drivers, they're likely
to set it as well.
I'm not quite sure where the best place to provide documentation on the
flag is. I've added the kernel doc comments to the structure, but maybe
it needs to be documented somewhere in Documentation/usb/?
Sarah Sharp
--
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
* [PATCH net-next] net: netdev_alloc_skb() use build_skb()
From: Eric Dumazet @ 2012-05-17 17:34 UTC (permalink / raw)
To: Willy Tarreau, David Miller; +Cc: netdev
In-Reply-To: <1337273387.3403.24.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
Please note I havent tested yet this patch, lacking hardware for this.
(tg3/bnx2/bnx2x use build_skb, r8169 does a copy of incoming frames,
ixgbe uses fragments...)
Any volunteer ?
Thanks
[PATCH net-next] net: netdev_alloc_skb() use build_skb()
netdev_alloc_skb() is used by networks driver in their RX path to
allocate an skb to receive an incoming frame.
With recent skb->head_frag infrastructure, it makes sense to change
netdev_alloc_skb() to use build_skb() and a frag allocator.
This permits a zero copy splice(socket->pipe), and better GRO or TCP
coalescing.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 2a18719..c02a8ec 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -293,6 +293,12 @@ struct sk_buff *build_skb(void *data, unsigned int frag_size)
}
EXPORT_SYMBOL(build_skb);
+struct netdev_alloc_cache {
+ struct page *page;
+ unsigned int offset;
+};
+static DEFINE_PER_CPU(struct netdev_alloc_cache, netdev_alloc_cache);
+
/**
* __netdev_alloc_skb - allocate an skbuff for rx on a specific device
* @dev: network device to receive on
@@ -310,8 +316,32 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
{
struct sk_buff *skb;
+ unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD) +
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
- skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, NUMA_NO_NODE);
+ if (fragsz <= PAGE_SIZE && !(gfp_mask & __GFP_WAIT)) {
+ struct netdev_alloc_cache *nc;
+ void *data = NULL;
+
+ nc = &get_cpu_var(netdev_alloc_cache);
+ if (!nc->page) {
+refill: nc->page = alloc_page(gfp_mask);
+ nc->offset = 0;
+ }
+ if (likely(nc->page)) {
+ if (nc->offset + fragsz > PAGE_SIZE) {
+ put_page(nc->page);
+ goto refill;
+ }
+ data = page_address(nc->page) + nc->offset;
+ nc->offset += fragsz;
+ get_page(nc->page);
+ }
+ put_cpu_var(netdev_alloc_cache);
+ skb = data ? build_skb(data, fragsz) : NULL;
+ } else {
+ skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, NUMA_NO_NODE);
+ }
if (likely(skb)) {
skb_reserve(skb, NET_SKB_PAD);
skb->dev = dev;
^ permalink raw reply related
* Re: [PATCH net-next] net: netdev_alloc_skb() use build_skb()
From: Willy Tarreau @ 2012-05-17 17:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1337276056.3403.37.camel@edumazet-glaptop>
On Thu, May 17, 2012 at 07:34:16PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Please note I havent tested yet this patch, lacking hardware for this.
>
> (tg3/bnx2/bnx2x use build_skb, r8169 does a copy of incoming frames,
> ixgbe uses fragments...)
>
> Any volunteer ?
>
> Thanks
>
> [PATCH net-next] net: netdev_alloc_skb() use build_skb()
>
> netdev_alloc_skb() is used by networks driver in their RX path to
> allocate an skb to receive an incoming frame.
>
> With recent skb->head_frag infrastructure, it makes sense to change
> netdev_alloc_skb() to use build_skb() and a frag allocator.
>
> This permits a zero copy splice(socket->pipe), and better GRO or TCP
> coalescing.
Impressed !
For the first time I could proxy HTTP traffic at gigabit speed on this
little box powered by USB ! I've long believed that proper splicing
would make this possible and now I'm seeing it is. Congrats Eric !
I'm still observing some stalls on medium-sized files (eg: 100k,
smaller than the pipe size, don't know yet if there is any relation).
I'll check closer and try to report something more exploitable.
Cheers,
Willy
^ permalink raw reply
* From Mr. Sameh Jawad
From: Mr. Sameh @ 2012-05-17 17:38 UTC (permalink / raw)
Good day,
Please I am looking for a profitable business where my client can invest some money.
I will be waiting for your positive investment idea/advice.
Best Regards,
Mr. Sameh Jawad.
^ permalink raw reply
* [PATCH v2] drop_monitor: convert to modular building
From: Neil Horman @ 2012-05-17 17:49 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David S. Miller, Eric Dumazet, Ben Hutchings
In-Reply-To: <1337178426-2470-1-git-send-email-nhorman@tuxdriver.com>
When I first wrote drop monitor I wrote it to just build monolithically. There
is no reason it can't be built modularly as well, so lets give it that
flexibiity.
I've tested this by building it as both a module and monolithically, and it
seems to work quite well
Change notes:
v2)
* fixed for_each_present_cpu loops to be more correct as per Eric D.
* Converted exit path failures to BUG_ON as per Ben H.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
---
net/Kconfig | 2 +-
net/core/drop_monitor.c | 46 ++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/net/Kconfig b/net/Kconfig
index e07272d..76ad6fa 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -295,7 +295,7 @@ config NET_TCPPROBE
module will be called tcp_probe.
config NET_DROP_MONITOR
- boolean "Network packet drop alerting service"
+ tristate "Network packet drop alerting service"
depends on INET && EXPERIMENTAL && TRACEPOINTS
---help---
This feature provides an alerting service to userspace in the
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index cfeeef8..b6760a6 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -24,6 +24,7 @@
#include <linux/timer.h>
#include <linux/bitops.h>
#include <linux/slab.h>
+#include <linux/module.h>
#include <net/genetlink.h>
#include <net/netevent.h>
@@ -225,9 +226,15 @@ static int set_all_monitor_traces(int state)
switch (state) {
case TRACE_ON:
+ if (!try_module_get(THIS_MODULE)) {
+ rc = -ENODEV;
+ break;
+ }
+
rc |= register_trace_kfree_skb(trace_kfree_skb_hit, NULL);
rc |= register_trace_napi_poll(trace_napi_poll_hit, NULL);
break;
+
case TRACE_OFF:
rc |= unregister_trace_kfree_skb(trace_kfree_skb_hit, NULL);
rc |= unregister_trace_napi_poll(trace_napi_poll_hit, NULL);
@@ -243,6 +250,9 @@ static int set_all_monitor_traces(int state)
kfree_rcu(new_stat, rcu);
}
}
+
+ module_put(THIS_MODULE);
+
break;
default:
rc = 1;
@@ -368,7 +378,7 @@ static int __init init_net_drop_monitor(void)
rc = 0;
- for_each_present_cpu(cpu) {
+ for_each_possible_cpu(cpu) {
data = &per_cpu(dm_cpu_data, cpu);
reset_per_cpu_data(data);
INIT_WORK(&data->dm_alert_work, send_dm_alert);
@@ -385,4 +395,36 @@ out:
return rc;
}
-late_initcall(init_net_drop_monitor);
+static void exit_net_drop_monitor(void)
+{
+ struct per_cpu_dm_data *data;
+ int cpu;
+
+ BUG_ON(unregister_netdevice_notifier(&dropmon_net_notifier));
+
+ /*
+ * Because of the module_get/put we do in the trace state change path
+ * we are guarnateed not to have any current users when we get here
+ * all we need to do is make sure that we don't have any running timers
+ * or pending schedule calls
+ */
+
+ for_each_possible_cpu(cpu) {
+ data = &per_cpu(dm_cpu_data, cpu);
+ del_timer(&data->send_timer);
+ cancel_work_sync(&data->dm_alert_work);
+ /*
+ * At this point, we should have exclusive access
+ * to this struct and can free the skb inside it
+ */
+ kfree_skb(data->skb);
+ }
+
+ BUG_ON(genl_unregister_family(&net_drop_monitor_family));
+}
+
+module_init(init_net_drop_monitor);
+module_exit(exit_net_drop_monitor);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Neil Horman <nhorman@tuxdriver.com>");
--
1.7.7.6
^ permalink raw reply related
* Re: [RFC 13/13] USB: Disable hub-initiated LPM for comms devices.
From: Andre Bella @ 2012-05-17 17:50 UTC (permalink / raw)
To: Tilman Schmidt, Sarah Sharp
Cc: gigaset307x-common, libertas-dev, Greg Kroah-Hartman, linux-usb,
linux-wireless, users, linux-bluetooth, ath9k-devel, Alan Stern,
Hansjoerg Lipp, netdev
In-Reply-To: <20120517173150.GE4967@xanatos>
[-- Attachment #1.1: Type: text/plain, Size: 2381 bytes --]
I dont know, sorry,
--- On Thu, 5/17/12, Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:
From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Subject: Re: [RFC 13/13] USB: Disable hub-initiated LPM for comms devices.
To: "Tilman Schmidt" <tilman@imap.cc>
Cc: gigaset307x-common@lists.sourceforge.net, libertas-dev@lists.infradead.org, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, users@rt2x00.serialmonkey.com, linux-bluetooth@vger.kernel.org, ath9k-devel@lists.ath9k.org, "Alan Stern" <stern@rowland.harvard.edu>, "Hansjoerg Lipp" <hjlipp@web.de>, netdev@vger.kernel.org
Date: Thursday, May 17, 2012, 1:31 PM
On Thu, May 17, 2012 at 07:07:32PM +0200, Tilman Schmidt wrote:
> Am 16.05.2012 23:55, schrieb Sarah Sharp:
> > Set the disable_hub_initiated_lpm flag for for all USB communications
> > drivers. I know there aren't currently any USB 3.0 devices that
> > implement these class specifications, but we should be ready if they do.
>
> I follow the argument for class drivers. But this patch also
> modifies drivers for specific existing USB 2.0 only devices
> which are unlikely to ever grow USB 3.0 support, such as the
> Gigaset ISDN driver:
>
> > drivers/isdn/gigaset/bas-gigaset.c | 1 +
> > drivers/isdn/gigaset/usb-gigaset.c | 1 +
Is there a particular reason why you think that driver is unlikely to
ever get USB 3.0 support? I pretty much grabbed any USB driver that
looked like a communications driver without looking too closely at the
code.
> What is the interest of setting the disable_hub_initiated_lpm
> flag for these?
It's partially to lay the foundation for anyone who wants to make a USB
3.0 communications driver in the future. They're likely to start from
some USB 2.0 class driver, and copy a lot of code. If they notice that
flag is set in all the USB communications class drivers, they're likely
to set it as well.
I'm not quite sure where the best place to provide documentation on the
flag is. I've added the kernel doc comments to the structure, but maybe
it needs to be documented somewhere in Documentation/usb/?
Sarah Sharp
_______________________________________________
libertas-dev mailing list
libertas-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/libertas-dev
[-- Attachment #1.2: Type: text/html, Size: 3157 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* Re: tcp timestamp issues with google servers
From: Eric Dumazet @ 2012-05-17 18:12 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: netdev, linux-kernel
In-Reply-To: <87r4ujno34.fsf@tucsk.pomaz.szeredi.hu>
On Thu, 2012-05-17 at 11:39 +0200, Miklos Szeredi wrote:
> Sometimes connection to google.com, gmail.com and other google servers
> doesn't work or takes ages to connect. When this hits it hits all
> google servers at the same time and it's persistent. It never happens
> to anything other than google. Rebooting helps. Rarely it goes away
> spontaneously.
>
> Apparently google is sometimes replying with an invalid TSecr timestamp
> value (smaller than the one sent in the last packet) and this confuses
> the Linux TCP stack which either discards the packet or sends a Reset.
>
> Network dump attached.
>
> I found only a couple of references to this issue:
>
> http://gotchas.livejournal.com/3028.html
>
> http://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/29f56feded11b42a
>
> Turning tcp timestamps fixes the issue:
>
> sysctl -w net.ipv4.tcp_timestamps=0
>
> Not sure why this happens only to me and a very few others.
>
> It appears to be an issue with google TCP stack (is it a modified
> stack?) but I thought about issues in my network switch (restarting it
> doesn't help) or something in the ISP, but those look unlikely.
>
> Any ideas?
>
> Thanks,
> Miklos
>
>
>
> 1 0.000000 192.168.28.100 -> 74.125.232.226 TCP 51303 > http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSV=35355050 TSER=0 WS=5
> 2 0.002730 74.125.232.226 -> 192.168.28.100 TCP http > 51303 [SYN, ACK] Seq=0 Ack=1 Win=14180 Len=0 MSS=1430 SACK_PERM=1 TSV=1184565067 TSER=35325344 WS=6
Do you really have 2730 usec RTT between you and this (Google ?)
server ?
Are you sure this is not a broken middle box ?
^ permalink raw reply
* Re: [PATCH v2] drop_monitor: convert to modular building
From: Ben Hutchings @ 2012-05-17 18:14 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <1337276940-5025-1-git-send-email-nhorman@tuxdriver.com>
On Thu, 2012-05-17 at 13:49 -0400, Neil Horman wrote:
> When I first wrote drop monitor I wrote it to just build monolithically. There
> is no reason it can't be built modularly as well, so lets give it that
> flexibiity.
>
> I've tested this by building it as both a module and monolithically, and it
> seems to work quite well
>
> Change notes:
>
> v2)
> * fixed for_each_present_cpu loops to be more correct as per Eric D.
> * Converted exit path failures to BUG_ON as per Ben H.
Sorry I didn't pick up on this the first time:
[...]
> -late_initcall(init_net_drop_monitor);
> +static void exit_net_drop_monitor(void)
> +{
> + struct per_cpu_dm_data *data;
> + int cpu;
> +
> + BUG_ON(unregister_netdevice_notifier(&dropmon_net_notifier));
> +
> + /*
> + * Because of the module_get/put we do in the trace state change path
> + * we are guarnateed not to have any current users when we get here
> + * all we need to do is make sure that we don't have any running timers
> + * or pending schedule calls
> + */
> +
> + for_each_possible_cpu(cpu) {
> + data = &per_cpu(dm_cpu_data, cpu);
> + del_timer(&data->send_timer);
Doesn't this need to be del_timer_sync()?
Ben.
> + cancel_work_sync(&data->dm_alert_work);
> + /*
> + * At this point, we should have exclusive access
> + * to this struct and can free the skb inside it
> + */
> + kfree_skb(data->skb);
> + }
> +
> + BUG_ON(genl_unregister_family(&net_drop_monitor_family));
> +}
> +
> +module_init(init_net_drop_monitor);
> +module_exit(exit_net_drop_monitor);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Neil Horman <nhorman@tuxdriver.com>");
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Stable regression with 'tcp: allow splice() to build full TSO packets'
From: Ben Hutchings @ 2012-05-17 18:38 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Eric Dumazet, netdev
In-Reply-To: <20120517155621.GK14498@1wt.eu>
On Thu, 2012-05-17 at 17:56 +0200, Willy Tarreau wrote:
[...]
> The NIC does not support TSO but I've seen an alternate driver for this
> NIC which pretends to do TSO and in fact builds header frags so that the
> NIC is able to send all frames at once. I think it's already what GSO is
> doing but I'm wondering whether it would be possible to get more speed
> by doing this than by relying on GSO to (possibly) split the frags earlier.
[...]
Yes, GSO has some overhead for skb allocation and additional function
calls that you can avoid by doing 'TSO' in the driver.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next] tcp: bool conversions
From: David Miller @ 2012-05-17 19:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337246134.4740.5.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 17 May 2012 11:15:34 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> bool conversions where possible.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, with commit message updated to reflect reality :-)
^ permalink raw reply
* Re: [net-next 0/4][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-05-17 19:12 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1337254070-32500-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 May 2012 04:27:46 -0700
> This series of patches contains updates for e1000, e1000e and igb.
>
> The following are changes since commit dc6b9b78234fecdc6d2ca5e1629185718202bcf5:
> net: include/net/sock.h cleanup
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v2] drop_monitor: convert to modular building
From: Neil Horman @ 2012-05-17 19:33 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <1337278445.2496.17.camel@bwh-desktop.uk.solarflarecom.com>
On Thu, May 17, 2012 at 07:14:05PM +0100, Ben Hutchings wrote:
> On Thu, 2012-05-17 at 13:49 -0400, Neil Horman wrote:
> > When I first wrote drop monitor I wrote it to just build monolithically. There
> > is no reason it can't be built modularly as well, so lets give it that
> > flexibiity.
> >
> > I've tested this by building it as both a module and monolithically, and it
> > seems to work quite well
> >
> > Change notes:
> >
> > v2)
> > * fixed for_each_present_cpu loops to be more correct as per Eric D.
> > * Converted exit path failures to BUG_ON as per Ben H.
>
> Sorry I didn't pick up on this the first time:
>
> [...]
> > -late_initcall(init_net_drop_monitor);
> > +static void exit_net_drop_monitor(void)
> > +{
> > + struct per_cpu_dm_data *data;
> > + int cpu;
> > +
> > + BUG_ON(unregister_netdevice_notifier(&dropmon_net_notifier));
> > +
> > + /*
> > + * Because of the module_get/put we do in the trace state change path
> > + * we are guarnateed not to have any current users when we get here
> > + * all we need to do is make sure that we don't have any running timers
> > + * or pending schedule calls
> > + */
> > +
> > + for_each_possible_cpu(cpu) {
> > + data = &per_cpu(dm_cpu_data, cpu);
> > + del_timer(&data->send_timer);
>
> Doesn't this need to be del_timer_sync()?
>
Yeah, good catch. I was thinking it didn't need to be as the timer doesn't
re-arm itself and the cancel_work_sync would undo anything that a running timer
did, but thinking about it, its possible that a timer could fire on cpu A, and
cpu B could execute and complete the cancel_work_sync prior to cpu A scheduling
it, so there is a race window there. I'll fix that up.
Neil
^ permalink raw reply
* Re: [net-next 2/4] e1000: remove workaround for Errata 23 from jumbo alloc
From: David Miller @ 2012-05-17 19:32 UTC (permalink / raw)
To: bhutchings; +Cc: jeffrey.t.kirsher, bigeasy, netdev, gospo, sassmann
In-Reply-To: <1337265630.2496.11.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 17 May 2012 15:40:30 +0100
> I don't believe PAGE_SIZE is >64K on any architecture, but perhaps you
> should replace the run-time check with:
powerpc can be built with PAGE_SHIFT == 18
^ permalink raw reply
* Re: [PATCH net-next-2.6] pppoe: remove unused return value from two methods.
From: David Miller @ 2012-05-17 19:35 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <CAHLOa7RiNcZBLE7z7JTY-7WJGOL_DTYq33hmwyTdM0HWqn_WgA@mail.gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Thu, 17 May 2012 18:04:50 +0300
> Hi,
>
> The patch removes unused return value from __delete_item() and
> delete_item() methods in drivers/net/ppp/pppoe.c.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, but please in the future:
1) Don't put "hi," "how are you" and things like in your message
body, I have to edit them out every time when I commit your
changes.
2) Remove that leading space from your commit message lines, I have
to edit those out as well.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] etherdevice: fix comments
From: David Miller @ 2012-05-17 19:37 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20120517081728.54719129@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 17 May 2012 08:17:28 -0700
> Fix some minor problems in comments of etherdevice.h
> * Warning is out dated, file hasn't moved or disappeared in many years and
> is unlikely to do so soon.
> * Capitalize Ethernet consistently since it is a proper name
> * Fix descriptive comment of padding
> * Spelling and grammar fix for alignment comment
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: correct the ipv6 option name - Pad0 to Pad1
From: David Miller @ 2012-05-17 19:50 UTC (permalink / raw)
To: eldad
Cc: yoshfuji, netdev, bridge, hadi, jmorris, linux-kernel, kuznet,
shemminger
In-Reply-To: <1337270425-21873-1-git-send-email-eldad@fogrefinery.com>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Thu, 17 May 2012 18:00:25 +0200
> The padding destination or hop-by-hop option is called Pad1 and not Pad0.
>
> See RFC2460 (4.2) or the IANA ipv6-parameters registry:
> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] net: netdev_alloc_skb() use build_skb()
From: David Miller @ 2012-05-17 19:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: w, netdev
In-Reply-To: <1337276056.3403.37.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 17 May 2012 19:34:16 +0200
> [PATCH net-next] net: netdev_alloc_skb() use build_skb()
>
> netdev_alloc_skb() is used by networks driver in their RX path to
> allocate an skb to receive an incoming frame.
>
> With recent skb->head_frag infrastructure, it makes sense to change
> netdev_alloc_skb() to use build_skb() and a frag allocator.
>
> This permits a zero copy splice(socket->pipe), and better GRO or TCP
> coalescing.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, we can sort out any fallout very easily before 3.5 is released.
Awesome work Eric.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox