* [REGRESSION,BISECTED] 3.11.7,3.12: GbE iface rate drops to few KB/s
From: Arnaud Ebalard @ 2013-11-11 10:27 UTC (permalink / raw)
To: Eric Dumazet, David S. Miller, Greg Kroah-Hartman
Cc: netdev, stable, linux-arm-kernel
Hi, [resending (previous msg did not hit netdev); also fixed subject]
I decided to upgrade the kernel on one of my ReadyNAS 102 from 3.11.1 to
3.11.7. The device is based on Marvell Armada 370 SoC and uses mvneta
driver. Mine runs Debian armel unstable but I can confirm the issue also
happens on a debian harmhf unstable.
Doing some scp transfers of files located on the NAS (1000baseT-FD on
both side), I noticed the transfers rate is ridiculously slow (280KB/s).
I did the same test with a 3.12 kernel and got the same results,
i.e. AFAICT the bug also exist upstream.
So, I decided to go to hell and start digging a bit: I run a 'git bisect'
session on stable tree from 3.11.1 (known good) to 3.11.7 (known
bad). The results are given below.
I decided to reboot on my old 3.11.1 kernel and do 20 files transfers
of a 1GB file located on the NAS to my laptop via scp. I took the 20+
minutes and let them all finish: each transfer took between 1min5s and
1min7s (around 16MB/s, the limitation in that case being the crypto part).
I rebooted again and did the exact same thing on the 3.11.7 and after
the completion of the first file transfer in 1m6s (16MB/s), the second
one gave me that:
arno@small:~scp RN102:/tmp/random /dev/null
random 0% 1664KB 278.9KB/s 1:05:37 ETA^C
And it continued that way for the remaining transfers (i did ^c after
some seconds to restart the transfer when the rate was low):
$ for k in $(seq 1 20) ; do scp RN102:random /dev/null ; done
random 100% 1024MB 15.6MB/s 01:06 ETA^C
random 0% 9856KB 282.2KB/s 1:01:20 ETA^C
random 16% 168MB 563.9KB/s 25:54 ETA^C
random 0% 2816KB 273.5KB/s 1:03:43 ETA^C
random 100% 1024MB 15.5MB/s 01:06
random 1% 17MB 282.3KB/s 1:00:54 ETA^C
random 0% 544KB 259.2KB/s 1:07:23 ETA^C
random 0% 4224KB 277.3KB/s 1:02:45 ETA^C
random 0% 832KB 262.1KB/s 1:06:37 ETA^C
random 0% 3360KB 273.4KB/s 1:03:43 ETA^C
random 0% 3072KB 271.8KB/s 1:04:07 ETA^C
random 0% 832KB 262.1KB/s 1:06:37 ETA^C
random 0% 1408KB 267.0KB/s 1:05:21 ETA^C
random 0% 1120KB 264.7KB/s 1:05:57 ETA
...
To be sure, I did 2 additional reboots, one on each kernel and the
result is consistent. Perfect on 3.11.1 and slow rate most of the time
on 3.11.7 (Both kernel are compiled from a fresh make clean, using the
same config file).
Then, knowing that, I started a git bisect session on stable tree to end
up with the following suspects. I failed to go any further to a single
commit, due to crashes, but I could recompile a kernel w/ debug info and
report what I get if neeeded.
commit dc0791aee672 tcp: do not forget FIN in tcp_shifted_skb() [bad]
commit 18ddf5127c9f tcp: must unclone packets before mangling them
commit 80bd5d8968d8 tcp: TSQ can use a dynamic limit
commit dbeb18b22197 tcp: TSO packets automatic sizing
commit 50704410d014 Linux 3.11.6 [good]
Eric, David, if it has already been reported and fixed, just tell
me. Otherwise, if you have any ideas, I'll be happy to test this
evening.
Cheers,
a+
Just in case it may be useful, here is what ethtool reports on RN102:
# ethtool -i eth0
driver: mvneta
version: 1.0
firmware-version:
bus-info: eth0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
# ethtool -k eth0
Features for eth0:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [fixed]
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
^ permalink raw reply
* Re: [PATCH] net bridge: add null pointer check, fix panic
From: Alexander Y. Fomichev @ 2013-11-11 10:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: xiaoming gao, stephen, davem, bridge, netdev, linux-kernel
In-Reply-To: <1371713342.3252.371.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 4775 bytes --]
On Thu, Jun 20, 2013 at 11:29 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2013-06-20 at 15:00 +0800, xiaoming gao wrote:
>
>> HI Eric
>> the problem is as follow:
>> br_del_if()-->del_nbp():
>>
>> list_del_rcu(&p->list);
>> dev->priv_flags &= ~IFF_BRIDGE_PORT;
>>
>> ------>at this point, the nic be deleting still have rx_handler , so , may in br_handle_frame()
>> ------>br_port_exists() will return false,so br_get_port_rcu() will return NULL
>> ------>so in br_handle_frame , there will be a null panic.
>>
>> netdev_rx_handler_unregister(dev);
>> synchronize_net();
>
> This code is no longer like that in current tree.
> Check commit 4a0b5ec12f0ffc3024616e6dc62cf8a04c54edcd
> ("bridge: remove a redundant synchronize_net()")
>
>>
>>
>> i have checked commit 00cfec37484761a44, i think it didn't fix this bug..
>
> I claim adding NULL tests is not needed in the fast path, it was clearly
> stated in the changelog.
>
> I would change the dismantle path to make sure br_get_port_rcu() does
> not return NULL in the fast path, and remove the test on FF_BRIDGE_PORT
> Try something like that :
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 1b8b8b8..2edfb80 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -60,7 +60,7 @@ static int br_pass_frame_up(struct sk_buff *skb)
> int br_handle_frame_finish(struct sk_buff *skb)
> {
> const unsigned char *dest = eth_hdr(skb)->h_dest;
> - struct net_bridge_port *p = br_port_get_rcu(skb->dev);
> + struct net_bridge_port *p = __br_port_get_rcu(skb->dev);
> struct net_bridge *br;
> struct net_bridge_fdb_entry *dst;
> struct net_bridge_mdb_entry *mdst;
> @@ -68,7 +68,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
> bool unicast = true;
> u16 vid = 0;
>
> - if (!p || p->state == BR_STATE_DISABLED)
> + if (p->state == BR_STATE_DISABLED)
> goto drop;
>
> if (!br_allowed_ingress(p->br, nbp_get_vlan_info(p), skb, &vid))
> @@ -142,7 +142,7 @@ drop:
> /* note: already called with rcu_read_lock */
> static int br_handle_local_finish(struct sk_buff *skb)
> {
> - struct net_bridge_port *p = br_port_get_rcu(skb->dev);
> + struct net_bridge_port *p = __br_port_get_rcu(skb->dev);
> u16 vid = 0;
>
> br_vlan_get_tag(skb, &vid);
> @@ -172,7 +172,7 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
> if (!skb)
> return RX_HANDLER_CONSUMED;
>
> - p = br_port_get_rcu(skb->dev);
> + p = __br_port_get_rcu(skb->dev);
>
> if (unlikely(is_link_local_ether_addr(dest))) {
> /*
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 3be89b3..9fdd467 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -184,6 +184,11 @@ struct net_bridge_port
>
> #define br_port_exists(dev) (dev->priv_flags & IFF_BRIDGE_PORT)
>
> +static inline struct net_bridge_port *__br_port_get_rcu(const struct net_device *dev)
> +{
> + return rcu_dereference(dev->rx_handler_data);
> +}
> +
> static inline struct net_bridge_port *br_port_get_rcu(const struct net_device *dev)
> {
> struct net_bridge_port *port =
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> I claim adding NULL tests is not needed in the fast path, it was clearly
> stated in the changelog.
Hello,
This commit makes trouble for current STP.
Two days ago i tried to switch to 3.10.18 and i've caught "bad magic"
on uninitialized br->lock:
./net/bridge/br_stp_bpdu.c +158 in br_stp_rcv (trace attached):
p = br_port_get_rcu(dev);
br = p->br;
spin_lock(&br->lock); <- here
-----------------------------------------------
Bisect pointed to this commit
(linux-stable: 960b8e5018a552f62cfbc0dfe94be7b6ba178f13)
(mainline 716ec052d2280d511e10e90ad54a86f5b5d4dcc2)
As far as i can see this happens when:
a) bridge module had been loaded but there was no bridge interface,
br->lock had not been initialized.
b) interface had been in promiscuous mod (tcpdump)
c) stp broadcasts 01:80:c2:00:00:00 coming to this iface
(llc_rcv drops PACKET_OTHERHOST to protect us in promiscuous mode
but seems like not a broadcasts)
d) and finally rx_handler_data had been initialised for this interface
( by macvlan in my case)
It seems like STP needs its own IFF_BRIDGE_PORT check.
probably an easiest option to check it in br_stp_rcv as before (or
probably in llc_rcv)...
--
Best regards.
Alexander Y. Fomichev <git.user@gmail.com>
[-- Attachment #2: br_stp_rcv-spin_lock.trace --]
[-- Type: application/octet-stream, Size: 5983 bytes --]
[ 1761.045223] BUG: soft lockup - CPU#6 stuck for 23s! [md1_resync:1597]
[ 1761.051701] Modules linked in: bridge stp llc macvlan ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport xt_conntrack nf_conntrack iptable_filter ip_tables [last unloaded: xt_owner]
[ 1761.068794] irq event stamp: 229014772
[ 1761.072564] hardirqs last enabled at (229014772): [<ffffffff8103e492>] vprintk_emit+0x1b2/0x460
[ 1761.081420] hardirqs last disabled at (229014771): [<ffffffff8103e324>] vprintk_emit+0x44/0x460
[ 1761.090191] softirqs last enabled at (229014700): [<ffffffff810444d8>] __do_softirq+0x178/0x2a0
[ 1761.099042] softirqs last disabled at (229014753): [<ffffffff816aa44c>] call_softirq+0x1c/0x30
[ 1761.107729] CPU: 6 PID: 1597 Comm: md1_resync Not tainted 3.10.17 #13
[ 1761.114199] Hardware name: Supermicro X9DRG-HF/X9DRG-HF, BIOS 1.0c 08/22/2012
[ 1761.121368] task: ffff88084f080000 ti: ffff88084f07a000 task.ti: ffff88084f07a000
[ 1761.128908] RIP: 0010:[<ffffffff81322c57>] [<ffffffff81322c57>] delay_tsc+0x37/0x60
[ 1761.136727] RSP: 0018:ffff88107fc03ad0 EFLAGS: 00000206
[ 1761.142073] RAX: 0000000000dc56cb RBX: ffffffff816a065c RCX: 0000000000000001
[ 1761.149250] RDX: 00000000001daa0a RSI: 0000000000dc569f RDI: 0000000000000001
[ 1761.156418] RBP: ffff88107fc03ad0 R08: 0000000000000006 R09: 0000000000000000
[ 1761.163577] R10: 0000000000000002 R11: 0000000000000002 R12: ffff88107fc03a48
[ 1761.170746] R13: ffffffff816a9d2f R14: ffff88107fc03ad0 R15: 000000002a552e2e
[ 1761.177903] FS: 0000000000000000(0000) GS:ffff88107fc00000(0000) knlGS:0000000000000000
[ 1761.186050] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1761.191826] CR2: 0000000001e18000 CR3: 0000000001974000 CR4: 00000000000407e0
[ 1761.199000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1761.206158] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1761.213316] Stack:
[ 1761.216583] ffff88107fc03ae0 ffffffff81322b5f ffff88107fc03b10 ffffffff816950a4
[ 1761.224124] 0000000000007465 ffff8810527a8000 ffff8810527a8000 ffff88084e96e000
[ 1761.231666] ffff88107fc03b30 ffffffff8132b344 ffff88104b5c1180 ffff8810527a8000
[ 1761.239214] Call Trace:
[ 1761.241686] <IRQ>
[ 1761.243619] [<ffffffff81322b5f>] __delay+0xf/0x20
[ 1761.248693] [<ffffffff816950a4>] __spin_lock_debug+0x43/0x7b
[ 1761.254474] [<ffffffff8132b344>] do_raw_spin_lock+0x44/0xc0
[ 1761.260158] [<ffffffff8169f929>] _raw_spin_lock+0x39/0x40
[ 1761.265681] [<ffffffffa005b3da>] ? br_stp_rcv+0x8a/0x3f0 [bridge]
[ 1761.271902] [<ffffffffa005b3da>] br_stp_rcv+0x8a/0x3f0 [bridge]
[ 1761.277941] [<ffffffffa000e160>] ? stp_proto_register+0xb0/0xb0 [stp]
[ 1761.284495] [<ffffffff816888e3>] ? printk+0x4d/0x4f
[ 1761.289494] [<ffffffff81044219>] ? local_bh_enable+0x89/0xf0
[ 1761.295275] [<ffffffffa000e160>] ? stp_proto_register+0xb0/0xb0 [stp]
[ 1761.301834] [<ffffffffa000e160>] ? stp_proto_register+0xb0/0xb0 [stp]
[ 1761.308416] [<ffffffffa000e248>] stp_pdu_rcv+0xe8/0xea0 [stp]
[ 1761.314299] [<ffffffffa000e160>] ? stp_proto_register+0xb0/0xb0 [stp]
[ 1761.320868] [<ffffffffa003e661>] llc_rcv+0x371/0x4e0 [llc]
[ 1761.326486] [<ffffffff815ee646>] __netif_receive_skb_core+0x5c6/0x700
[ 1761.333046] [<ffffffff815ee17a>] ? __netif_receive_skb_core+0xfa/0x700
[ 1761.339694] [<ffffffff810a098f>] ? __lock_release+0x6f/0x100
[ 1761.345469] [<ffffffff815f23e1>] __netif_receive_skb+0x21/0x70
[ 1761.351421] [<ffffffff815f25f3>] netif_receive_skb+0x23/0xf0
[ 1761.357203] [<ffffffff8139f220>] ? dma_issue_pending_all+0xb0/0xe0
[ 1761.363495] [<ffffffff815f36e8>] napi_gro_receive+0xe8/0x140
[ 1761.369283] [<ffffffff814ee0f8>] igb_clean_rx_irq+0x148/0x1c0
[ 1761.375143] [<ffffffff814ee1ce>] igb_poll+0x5e/0xa0
[ 1761.380162] [<ffffffff815f2a29>] net_rx_action+0x139/0x250
[ 1761.385768] [<ffffffff81044409>] ? __do_softirq+0xa9/0x2a0
[ 1761.391375] [<ffffffff81044450>] __do_softirq+0xf0/0x2a0
[ 1761.396828] [<ffffffff816aa44c>] call_softirq+0x1c/0x30
[ 1761.402183] [<ffffffff81003e7d>] do_softirq+0x8d/0xc0
[ 1761.407349] [<ffffffff8104479e>] irq_exit+0xae/0xd0
[ 1761.412352] [<ffffffff816aa993>] do_IRQ+0x63/0xe0
[ 1761.417179] [<ffffffff816a05af>] common_interrupt+0x6f/0x6f
[ 1761.422887] <EOI>
[ 1761.424821] [<ffffffff811072e1>] ? get_page_from_freelist+0x241/0x5d0
[ 1761.431610] [<ffffffff811081c2>] __alloc_pages_nodemask+0x182/0xa50
[ 1761.437989] [<ffffffff8109fe61>] ? __lock_acquire+0x3f1/0xa80
[ 1761.443848] [<ffffffff8106fbe3>] ? finish_task_switch+0x83/0xf0
[ 1761.449905] [<ffffffff8109fe61>] ? __lock_acquire+0x3f1/0xa80
[ 1761.455799] [<ffffffff812ffae6>] ? ioc_lookup_icq+0x86/0xf0
[ 1761.461486] [<ffffffff811998c1>] ? bio_alloc_bioset+0x161/0x1c0
[ 1761.467536] [<ffffffff8114239a>] alloc_pages_current+0xba/0x170
[ 1761.473568] [<ffffffff815663a4>] r10buf_pool_alloc+0x174/0x2c0
[ 1761.479531] [<ffffffff8110241e>] mempool_alloc+0x5e/0x160
[ 1761.485044] [<ffffffff815676c6>] sync_request+0x916/0x1180
[ 1761.490650] [<ffffffff81570af1>] ? is_mddev_idle+0x141/0x170
[ 1761.496439] [<ffffffff815709b5>] ? is_mddev_idle+0x5/0x170
[ 1761.502039] [<ffffffff81573c98>] md_do_sync+0x548/0xd10
[ 1761.507385] [<ffffffff8106fbe3>] ? finish_task_switch+0x83/0xf0
[ 1761.513418] [<ffffffff81063b60>] ? __init_waitqueue_head+0x60/0x60
[ 1761.519720] [<ffffffff81570d8d>] md_thread+0x11d/0x170
[ 1761.524972] [<ffffffff8109e91d>] ? trace_hardirqs_on+0xd/0x10
[ 1761.530840] [<ffffffff81570c70>] ? md_register_thread+0xf0/0xf0
[ 1761.536879] [<ffffffff8106304b>] kthread+0xdb/0xe0
[ 1761.541795] [<ffffffff81062f70>] ? __init_kthread_worker+0x70/0x70
[ 1761.548094] [<ffffffff816a8f5c>] ret_from_fork+0x7c/0xb0
[ 1761.553530] [<ffffffff81062f70>] ? __init_kthread_worker+0x70/0x70
[ 1761.559829] Code: 04 25 1c b0 00 00 0f 1f 00 0f ae e8 0f 31 89 c6 eb 11 66 90 f3 90 65 8b 0c 25 1c b0 00 00 41 39 c8 75 12 0f 1f 00 0f ae e8 0f 31 <89> c2 29 f2 39 fa 72 e1 5d c3 29 c6 01 f7 0f 1f 00 0f ae e8 0f
[-- Attachment #3: fix_stp_bridge_uninitialized.patch --]
[-- Type: application/x-download, Size: 477 bytes --]
^ permalink raw reply
* Re: spurious ip forwarding inside namespaces
From: Maciej Żenczykowski @ 2013-11-11 10:01 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Nicolas Dichtel, David S. Miller, Linux NetDev
In-Reply-To: <CAMEtUuz70qyDgB1-EH9xPK71PagxwHFVCzmrnwC2uWum_gxxFg@mail.gmail.com>
I didn't really understand what he was trying to fix (seemed like a
userspace misconfiguration issue to me…), but it seems pretty clear
that this is not the right way to go about it.
Ignoring destination mac address is not the right way to go about doing things.
^ permalink raw reply
* Re: [PATCH v2] mac80211: add assoc beacon timeout logic
From: Johannes Berg @ 2013-11-11 9:08 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-wireless, netdev, John W. Linville, David S. Miller
In-Reply-To: <1384119945-31213-1-git-send-email-felipe.contreras@gmail.com>
On Sun, 2013-11-10 at 15:45 -0600, Felipe Contreras wrote:
> We don't want to be waiting forever for a beacon that will never come,
> just continue the association.
This makes no sense, IMO.
If there really are no beacons at all, then nothing can work with the AP
-- things like HT, regulatory/radar, powersave, multiple virtual
interfaces and many others require beacons.
If the AP is sending beacons but the device isn't receiving them, then
it's a driver bug and mac80211 shouldn't work around it.
johannes
^ permalink raw reply
* Re: [PATCH] ipv6: match those routes that have different metirc
From: Duan Jiong @ 2013-11-11 8:29 UTC (permalink / raw)
To: hannes; +Cc: David Miller, netdev
In-Reply-To: <20131111073923.GB27030@order.stressinduktion.org>
于 2013年11月11日 15:39, Hannes Frederic Sowa 写道:
> On Mon, Nov 11, 2013 at 03:16:24PM +0800, Duan Jiong wrote:
>> 于 2013年11月11日 14:07, Hannes Frederic Sowa 写道:
>>> On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote:
>>>> Now the kernel only match those routes that have the same
>>>> metirc, so if those routes are non-reachable, then the packets
>>>> can't be sent out.
>>>>
>>>> But according to the rfc 4191 section 3.2, if the best route
>>>> points to a non-reachable route, the next best route should be
>>>> consulted. So the kernel should not only match those routes that
>>>> have minimum metric, and should also match others.
>>>
>>> I am not so keen on chaning how metrics get handled. Please note that
>>> metrics are a pure linux-centric concept and are not standardized. I bet
>>> some people depend on how these work and have the same semantic as IPv4
>>> ones because they use the same code in their routing daemon backends.
>>>
>>
>> I have a question. If we only match those routes that have lowest metric, others
>> will never be used, so why the other routes are inserted to the router table?
>
> Metrics could get used by software which manages dynamic interfaces, e.g.
> vpn/ppp software, to make sure they have priority over the current routing
> settings. If we don't respect metrics there, this could lead to security
> problems. (if the interface vanishes, the other route gets active again).
>
> It could also be used by dynamic routing software, e.g. is-is, ospf, bgp and
> does reflect the admins choice where traffic should get routed. Some routing
> daemon apply the whole routing table to the fib. If we don't respect metrics
> there, they could lose money, because maybe they pay for the traffic.
> They really get interesting if you have more than one routing protocol active
> at the same time. ;)
>
Thanks for your reply. I think i don't fully understand the metric, and this
patch should be ignored!
I am sorry that bothers your.
Thanks,
Duan
^ permalink raw reply
* Re: TCP performance regression
From: Sujith Manoharan @ 2013-11-11 8:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1384152853.16391.19.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet wrote:
> Hmm... apparently ath9k uses :
>
> #define ATH_AMPDU_LIMIT_MAX (64 * 1024 - 1)
This is the maximum AMPDU size, specified in the
802.11 standard.
> And mentions a 4ms time frame :
>
> max_4ms_framelen = ATH_AMPDU_LIMIT_MAX;
The 4ms limitation is a FCC limitation and is used
for regulatory compliance.
> So prior to "tcp: TSQ can use a dynamic limit", the ~128KB bytes TCP
> could queue per TCP socket on qdisc/NIC would happen to please ath9k
Ok.
> ath9k can set rts_aggr_limit to 8*1024 :
>
> if (AR_SREV_9160_10_OR_LATER(ah) || AR_SREV_9100(ah))
> pCap->rts_aggr_limit = ATH_AMPDU_LIMIT_MAX;
> else
> pCap->rts_aggr_limit = (8 * 1024);
The RTS limit is required for some old chips which had HW bugs and
the above code is a workaround.
> A timer would be definitely needed, and it should be rather small (1 or
> 2 ms)
>
> If TCP socket is application limited, it seems ath9k can delay the last
> block by a too long time.
I am not really clear on how this regression can be fixed in the driver
since the majority of the transmission/aggregation logic is present in the
TX completion path.
Sujith
^ permalink raw reply
* Re: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
From: Ingo Molnar @ 2013-11-11 8:23 UTC (permalink / raw)
To: wangbiao
Cc: oneukum, netdev, linux-usb, linux-kernel, akpm, mingo,
a.p.zijlstra, rusty, william.douglas
In-Reply-To: <1384139315.2179.9.camel@wangbiao>
* wangbiao <biao.wang@intel.com> wrote:
> @@ -1448,8 +1448,10 @@ static void usbnet_bh (unsigned long param)
>
> // waiting for all pending urbs to complete?
> if (dev->wait) {
> + wait_queue_head_t *wait_d = dev->wait;
> if ((dev->txq.qlen + dev->rxq.qlen + dev->done.qlen) == 0) {
> - wake_up (dev->wait);
> + if (wait_d)
> + wake_up(wait_d);
> }
>
> // or are we maybe short a few urbs?
1)
Nit: the scope of 'wait_d' is unnecessarily broad, it could be moved to
the block that uses it.
2)
Also, the changelog mentions that dev->wait can race - it would be nice to
add to the changelog what exact synchronization mechanism protects
usbnet_terminate_urbs() and usbnet_bh() from seeing/modifying that value
at once - as the code was clearly written without such interaction in
mind.
> @@ -1602,6 +1604,7 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
> init_timer (&dev->delay);
> mutex_init (&dev->phy_mutex);
> mutex_init(&dev->interrupt_mutex);
> + init_waitqueue_head(&unlink_wakeup);
3)
Can that runtime initialization be avoided by using
DECLARE_WAIT_QUEUE_HEAD()?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
From: Oliver Neukum @ 2013-11-11 7:44 UTC (permalink / raw)
To: wangbiao
Cc: netdev, linux-usb, linux-kernel, akpm, mingo, a.p.zijlstra, rusty,
william.douglas
In-Reply-To: <1384139315.2179.9.camel@wangbiao>
On Mon, 2013-11-11 at 11:08 +0800, wangbiao wrote:
> From: wang, biao <biao.wang@intel.com>
> Date: Mon, 11 Nov 2013 10:23:40 +0800
> Subject: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
>
> there is race between usbnet_terminate_urbs and usbnet_bh, when
> unlink_wakeup used in usbnet_bh, it may be already freed and used by
> other function as unlink_wakeup was a local var on stack.
Hi,
the debugging is good, but the fix is not good.
If you use a global variable, you can init the head
only once, that is on module load, not during probe()
Doing so can mess up operations with multiple modules
as a hotplug happens.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] ipv6: match those routes that have different metirc
From: Hannes Frederic Sowa @ 2013-11-11 7:39 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <52808448.3020206@cn.fujitsu.com>
On Mon, Nov 11, 2013 at 03:16:24PM +0800, Duan Jiong wrote:
> 于 2013年11月11日 14:07, Hannes Frederic Sowa 写道:
> > On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote:
> >> Now the kernel only match those routes that have the same
> >> metirc, so if those routes are non-reachable, then the packets
> >> can't be sent out.
> >>
> >> But according to the rfc 4191 section 3.2, if the best route
> >> points to a non-reachable route, the next best route should be
> >> consulted. So the kernel should not only match those routes that
> >> have minimum metric, and should also match others.
> >
> > I am not so keen on chaning how metrics get handled. Please note that
> > metrics are a pure linux-centric concept and are not standardized. I bet
> > some people depend on how these work and have the same semantic as IPv4
> > ones because they use the same code in their routing daemon backends.
> >
>
> I have a question. If we only match those routes that have lowest metric, others
> will never be used, so why the other routes are inserted to the router table?
Metrics could get used by software which manages dynamic interfaces, e.g.
vpn/ppp software, to make sure they have priority over the current routing
settings. If we don't respect metrics there, this could lead to security
problems. (if the interface vanishes, the other route gets active again).
It could also be used by dynamic routing software, e.g. is-is, ospf, bgp and
does reflect the admins choice where traffic should get routed. Some routing
daemon apply the whole routing table to the fib. If we don't respect metrics
there, they could lose money, because maybe they pay for the traffic.
They really get interesting if you have more than one routing protocol active
at the same time. ;)
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] ipv6: match those routes that have different metirc
From: Duan Jiong @ 2013-11-11 7:16 UTC (permalink / raw)
To: hannes; +Cc: David Miller, netdev
In-Reply-To: <20131111060753.GA27030@order.stressinduktion.org>
于 2013年11月11日 14:07, Hannes Frederic Sowa 写道:
> On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote:
>> Now the kernel only match those routes that have the same
>> metirc, so if those routes are non-reachable, then the packets
>> can't be sent out.
>>
>> But according to the rfc 4191 section 3.2, if the best route
>> points to a non-reachable route, the next best route should be
>> consulted. So the kernel should not only match those routes that
>> have minimum metric, and should also match others.
>
> I am not so keen on chaning how metrics get handled. Please note that
> metrics are a pure linux-centric concept and are not standardized. I bet
> some people depend on how these work and have the same semantic as IPv4
> ones because they use the same code in their routing daemon backends.
>
I have a question. If we only match those routes that have lowest metric, others
will never be used, so why the other routes are inserted to the router table?
Thanks,
Duan
> Also, I think it is better targetted for net-next, which is currently closed.
> So we have some time to discuss. ;)
>
> Greetings,
>
> Hannes
>
>
^ permalink raw reply
* Re: [PATCH v3 net-next] xfrm: Add check to prevent un-complete key manager
From: Fan Du @ 2013-11-11 7:11 UTC (permalink / raw)
To: baker.kernel; +Cc: davem, herbert, steffen.klassert, netdev, linux-kernel
In-Reply-To: <1384151951-13549-1-git-send-email-baker.kernel@gmail.com>
On 2013年11月11日 14:39, baker.kernel@gmail.com wrote:
> From: Baker Zhang<Baker.kernel@gmail.com>
>
> "acquire" and "compile_policy" callbacks are necessary for a key manager.
>
> Signed-off-by: Baker Zhang<Baker.kernel@gmail.com>
> ---
> Thanks for all reply.
>
> V1:
> For current kernel source, there is no problem.
>
> In our vpn product, we need a xfrm_km in kernel module
> to monitor the xfrm state change.
> thus, the 'acquire' and 'compile_policy' may be NULL.
>
> So I think we should do the check before use it.
>
> V2:
> Align the continuation line according the networking coding style.
>
> V3:
> Add check to prevent un-complete key manager at register time.
>
> net/xfrm/xfrm_state.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> index b9c3f9e..178283e 100644
> --- a/net/xfrm/xfrm_state.c
> +++ b/net/xfrm/xfrm_state.c
> @@ -1806,6 +1806,9 @@ static DEFINE_SPINLOCK(xfrm_km_lock);
>
> int xfrm_register_km(struct xfrm_mgr *km)
> {
> + if (km->acquire == NULL || km->compile_policy == NULL)
"acquire" is a MUST, "compile_policy" is not a necessity.
From the fist commit log, you probably add functionality providing SA state changes
in your private key manager, which current implementation does not. Maybe it's worthwhile
to elaborate the missing functionality than add those checking, because both key manage
(pfkeyv2/netlink) in use has "acquire" and "compile_policy" at the same time.
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* Re: TCP performance regression
From: Eric Dumazet @ 2013-11-11 6:54 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: netdev
In-Reply-To: <21120.29720.673157.151074@gargle.gargle.HOWL>
On Mon, 2013-11-11 at 11:37 +0530, Sujith Manoharan wrote:
> Eric Dumazet wrote:
> > I am afraid this commit shows bugs in various network drivers.
> >
> > All drivers doing TX completion using a timer are buggy.
> >
> > Holding skb 10 ms before TX completion is totally wrong and must be fixed.
> >
> > If really NIC is not able to trigger an interrupt after TX completion, then
> > driver should call skb_orphan() in its ndo_start_xmit()
>
> 802.11 AMPDU formation is done in the TX completion path in ath9k.
>
> Incoming frames are added to a software queue and the TX completion
> tasklet checks if enough frames are available to form an aggregate and
> if so, forms new aggregates and transmits them.
>
Hmm... apparently ath9k uses :
#define ATH_AMPDU_LIMIT_MAX (64 * 1024 - 1)
And mentions a 4ms time frame :
max_4ms_framelen = ATH_AMPDU_LIMIT_MAX;
So prior to "tcp: TSQ can use a dynamic limit", the ~128KB bytes TCP
could queue per TCP socket on qdisc/NIC would happen to please ath9k
ath9k can set rts_aggr_limit to 8*1024 :
if (AR_SREV_9160_10_OR_LATER(ah) || AR_SREV_9100(ah))
pCap->rts_aggr_limit = ATH_AMPDU_LIMIT_MAX;
else
pCap->rts_aggr_limit = (8 * 1024);
> There is no timer involved, but the completion routine is rather heavy.
> Many wireless drivers handle 802.11 aggregation in this way:
> ath9k, ath9k_htc, ath10k etc.
>
A timer would be definitely needed, and it should be rather small (1 or
2 ms)
If TCP socket is application limited, it seems ath9k can delay the last
block by a too long time.
^ permalink raw reply
* Re: spurious ip forwarding inside namespaces
From: Alexei Starovoitov @ 2013-11-11 6:51 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Nicolas Dichtel, David S. Miller, Linux NetDev
In-Reply-To: <CAHo-Oow6h1LRNw5DMb4+6bdwy31WGOTNokKe=C5cj40dDhTyQQ@mail.gmail.com>
On Sun, Nov 10, 2013 at 9:12 PM, Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
> I've already suggested a month or so back that that patch should be reverted.
Isaku's email (author of offending patch) was bouncing whole week.
Didn't have time last week to come up with a good fix.
Reverting fixes 'spurious ip forwarding', but Isaku's original problem
needs to be fixed somehow.
May be going through loopback should set pkt_type?
Alexei
> On Tue, Nov 5, 2013 at 8:32 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
>> Hi All,
>>
>> commit 06a23fe31c
>> "core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()"
>> and refactoring 64261f230a
>> "dev: move skb_scrub_packet() after eth_type_trans()"
>>
>> are forcing pkt_type to be PACKET_HOST when skb traverses veth.
>>
>> which means that ip forwarding will kick in inside netns
>> even if skb->eth->h_dest != dev->dev_addr
>>
>> The way we hit the problem is the following:
>> create 4 or more of netns with veth and attach them to a bridge.
>> disable learning on a bridge (via setageing 0), so it will flood
>> packets to all namespaces.
>> Since ip forwarding and icmp redirect by default is on,
>> single icmp request packet from one netns creates a storm of packets,
>> since every netns receives it and incorrectly does ip forward on it
>> and also incorrectly sends icmp redirect which are multiplied once
>> again by flooding in the bridge.
>> ping -c1 generates 1 outgoing packet and ~13K incoming packets with
>> just 4 netns.
>> Running any tcp traffic between such namespaces becomes impossible
>> and ksoftirqd cpu usage goes to 100% on all cpus.
>>
>> Please suggest how to fix this cleanly.
>>
>> Thanks
>> Alexei
>> --
>> 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
^ permalink raw reply
* Re: [PATCH v2] mac80211: add assoc beacon timeout logic
From: Krishna Chaitanya @ 2013-11-11 6:41 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-wireless, netdev, John W. Linville, Johannes Berg,
David S. Miller
In-Reply-To: <1384119945-31213-1-git-send-email-felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Nov 11, 2013 at 3:15 AM, Felipe Contreras
<felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> We don't want to be waiting forever for a beacon that will never come,
> just continue the association.
>
> Signed-off-by: Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>
> The previous version depended on some cleanup patches, plus had some unclear
> rerun logic.
>
> net/mac80211/ieee80211_i.h | 1 +
> net/mac80211/mlme.c | 32 ++++++++++++++++++++++++++------
> 2 files changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 611abfc..e1f858d 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -358,6 +358,7 @@ struct ieee80211_mgd_assoc_data {
> const u8 *supp_rates;
>
> unsigned long timeout;
> + unsigned long beacon_timeout;
> int tries;
>
> u16 capability;
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 86e4ad5..68f76f7 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -38,6 +38,7 @@
> #define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
> #define IEEE80211_ASSOC_TIMEOUT_LONG (HZ / 2)
> #define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
> +#define IEEE80211_ASSOC_BEACON_TIMEOUT 2 * HZ
Don't you think its too long? 3-4 beacon intervals should suffice.
> #define IEEE80211_ASSOC_MAX_TRIES 3
>
> static int max_nullfunc_tries = 2;
> @@ -3475,6 +3476,24 @@ void ieee80211_mgd_conn_tx_status(struct ieee80211_sub_if_data *sdata,
> ieee80211_queue_work(&local->hw, &sdata->work);
> }
>
> +static int check_beacon(struct ieee80211_sub_if_data *sdata)
> +{
> + struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> + struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
> +
> + if (!assoc_data->need_beacon || ifmgd->have_beacon)
> + return true;
> +
> + if (time_after(jiffies, assoc_data->beacon_timeout)) {
> + sdata_info(sdata, "no beacon from %pM\n", assoc_data->bss->bssid);
> + return true;
> + }
> +
> + assoc_data->timeout = TU_TO_EXP_TIME(assoc_data->bss->beacon_interval);
> + run_again(sdata, assoc_data->timeout);
> + return false;
> +}
> +
> void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
> {
> struct ieee80211_local *local = sdata->local;
> @@ -3533,12 +3552,12 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
>
> if (ifmgd->assoc_data && ifmgd->assoc_data->timeout_started &&
> time_after(jiffies, ifmgd->assoc_data->timeout)) {
> - if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
> - ieee80211_do_assoc(sdata)) {
> - struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
> -
> - ieee80211_destroy_assoc_data(sdata, false);
> - cfg80211_assoc_timeout(sdata->dev, bss);
> + if (check_beacon(sdata)) {
> + if (ieee80211_do_assoc(sdata)) {
> + struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
> + ieee80211_destroy_assoc_data(sdata, false);
> + cfg80211_assoc_timeout(sdata->dev, bss);
> + }
> }
> } else if (ifmgd->assoc_data && ifmgd->assoc_data->timeout_started)
> run_again(sdata, ifmgd->assoc_data->timeout);
> @@ -4335,6 +4354,7 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data *sdata,
> sdata_info(sdata, "waiting for beacon from %pM\n",
> ifmgd->bssid);
> assoc_data->timeout = TU_TO_EXP_TIME(req->bss->beacon_interval);
> + assoc_data->beacon_timeout = jiffies + IEEE80211_ASSOC_BEACON_TIMEOUT;
> assoc_data->timeout_started = true;
> assoc_data->need_beacon = true;
> } else if (beacon_ies) {
> --
> 1.8.4.2+fc1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 v3 net-next] xfrm: Add check to prevent un-complete key manager
From: baker.kernel @ 2013-11-11 6:39 UTC (permalink / raw)
To: davem, herbert, steffen.klassert; +Cc: netdev, linux-kernel, Baker Zhang
In-Reply-To: <1384093556-8987-1-git-send-email-baker.kernel@gmail.com>
From: Baker Zhang <Baker.kernel@gmail.com>
"acquire" and "compile_policy" callbacks are necessary for a key manager.
Signed-off-by: Baker Zhang <Baker.kernel@gmail.com>
---
Thanks for all reply.
V1:
For current kernel source, there is no problem.
In our vpn product, we need a xfrm_km in kernel module
to monitor the xfrm state change.
thus, the 'acquire' and 'compile_policy' may be NULL.
So I think we should do the check before use it.
V2:
Align the continuation line according the networking coding style.
V3:
Add check to prevent un-complete key manager at register time.
net/xfrm/xfrm_state.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index b9c3f9e..178283e 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1806,6 +1806,9 @@ static DEFINE_SPINLOCK(xfrm_km_lock);
int xfrm_register_km(struct xfrm_mgr *km)
{
+ if (km->acquire == NULL || km->compile_policy == NULL)
+ return -EINVAL;
+
spin_lock_bh(&xfrm_km_lock);
list_add_tail_rcu(&km->list, &xfrm_km_list);
spin_unlock_bh(&xfrm_km_lock);
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] ipv6: protect for_each_sk_fl_rcu in mem_check with rcu_read_lock_bh
From: David Miller @ 2013-11-11 6:26 UTC (permalink / raw)
To: hannes; +Cc: netdev, florent.fourcot
In-Reply-To: <20131108182621.GA404@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 8 Nov 2013 19:26:21 +0100
> Fixes a suspicious rcu derference warning.
>
> Cc: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Looks good, applied and queued up for -stable.
^ permalink raw reply
* [PATCH] xtsonic: add missing platform_set_drvdata() in xtsonic_probe()
From: Wei Yongjun @ 2013-11-11 6:17 UTC (permalink / raw)
To: davem, wfp5p, gregkh, michael.opdenacker, joe; +Cc: yongjun_wei, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add missing platform_set_drvdata() in xtsonic_probe(), otherwise
calling platform_get_drvdata() in xtsonic_device_remove() may
returns NULL.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/natsemi/xtsonic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/natsemi/xtsonic.c b/drivers/net/ethernet/natsemi/xtsonic.c
index 4da172a..7007d21 100644
--- a/drivers/net/ethernet/natsemi/xtsonic.c
+++ b/drivers/net/ethernet/natsemi/xtsonic.c
@@ -264,6 +264,7 @@ int xtsonic_probe(struct platform_device *pdev)
lp = netdev_priv(dev);
lp->device = &pdev->dev;
+ platform_set_drvdata(pdev, dev);
SET_NETDEV_DEV(dev, &pdev->dev);
netdev_boot_setup_check(dev);
^ permalink raw reply related
* [PATCH] macmace: add missing platform_set_drvdata() in mace_probe()
From: Wei Yongjun @ 2013-11-11 6:16 UTC (permalink / raw)
To: davem, wfp5p, gregkh, joe; +Cc: yongjun_wei, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add missing platform_set_drvdata() in mace_probe(), otherwise
calling platform_get_drvdata() in mac_mace_device_remove() may
returns NULL.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/apple/macmace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/apple/macmace.c b/drivers/net/ethernet/apple/macmace.c
index 4ce8ceb..58a200d 100644
--- a/drivers/net/ethernet/apple/macmace.c
+++ b/drivers/net/ethernet/apple/macmace.c
@@ -211,6 +211,7 @@ static int mace_probe(struct platform_device *pdev)
mp = netdev_priv(dev);
mp->device = &pdev->dev;
+ platform_set_drvdata(pdev, dev);
SET_NETDEV_DEV(dev, &pdev->dev);
dev->base_addr = (u32)MACE_BASE;
^ permalink raw reply related
* [PATCH] ethernet/arc/arc_emac: add missing platform_set_drvdata() in arc_emac_probe()
From: Wei Yongjun @ 2013-11-11 6:15 UTC (permalink / raw)
To: grant.likely, rob.herring, davem, abrodkin, vgupta; +Cc: yongjun_wei, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add missing platform_set_drvdata() in arc_emac_probe(), otherwise
calling platform_get_drvdata() in arc_emac_remove() may returns NULL.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/arc/emac_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 9e16014..cbaa7f9 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -671,6 +671,7 @@ static int arc_emac_probe(struct platform_device *pdev)
if (!ndev)
return -ENOMEM;
+ platform_set_drvdata(pdev, ndev);
SET_NETDEV_DEV(ndev, &pdev->dev);
ndev->netdev_ops = &arc_emac_netdev_ops;
^ permalink raw reply related
* Re: TCP performance regression
From: Sujith Manoharan @ 2013-11-11 6:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1384149326.16391.10.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet wrote:
> I am afraid this commit shows bugs in various network drivers.
>
> All drivers doing TX completion using a timer are buggy.
>
> Holding skb 10 ms before TX completion is totally wrong and must be fixed.
>
> If really NIC is not able to trigger an interrupt after TX completion, then
> driver should call skb_orphan() in its ndo_start_xmit()
802.11 AMPDU formation is done in the TX completion path in ath9k.
Incoming frames are added to a software queue and the TX completion
tasklet checks if enough frames are available to form an aggregate and
if so, forms new aggregates and transmits them.
There is no timer involved, but the completion routine is rather heavy.
Many wireless drivers handle 802.11 aggregation in this way:
ath9k, ath9k_htc, ath10k etc.
Sujith
^ permalink raw reply
* Re: [PATCH] ipv6: match those routes that have different metirc
From: Hannes Frederic Sowa @ 2013-11-11 6:07 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <52804865.8090206@cn.fujitsu.com>
On Mon, Nov 11, 2013 at 11:00:53AM +0800, Duan Jiong wrote:
> Now the kernel only match those routes that have the same
> metirc, so if those routes are non-reachable, then the packets
> can't be sent out.
>
> But according to the rfc 4191 section 3.2, if the best route
> points to a non-reachable route, the next best route should be
> consulted. So the kernel should not only match those routes that
> have minimum metric, and should also match others.
I am not so keen on chaning how metrics get handled. Please note that
metrics are a pure linux-centric concept and are not standardized. I bet
some people depend on how these work and have the same semantic as IPv4
ones because they use the same code in their routing daemon backends.
Also, I think it is better targetted for net-next, which is currently closed.
So we have some time to discuss. ;)
Greetings,
Hannes
^ permalink raw reply
* Re: TCP performance regression
From: Eric Dumazet @ 2013-11-11 5:55 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: Eric Dumazet, netdev
In-Reply-To: <21120.27501.32323.332316@gargle.gargle.HOWL>
On Mon, 2013-11-11 at 11:00 +0530, Sujith Manoharan wrote:
> Hi,
>
> The commit, "tcp: TSQ can use a dynamic limit" causes a large
> performance drop in TCP transmission with the wireless driver ath9k.
>
> With a 2-stream card (AR9462), the usual throughput is around 195 Mbps.
> But, with this commit, it drops to ~125 Mbps, occasionally reaching 130.
>
> If the commit is reverted, performance is normal again and I can get
> 190+ Mbps. Apparently, ath10k is also affected and a 250 Mbps drop
> is seen (from an original 740 Mbps).
I am afraid this commit shows bugs in various network drivers.
All drivers doing TX completion using a timer are buggy.
Random example : drivers/net/ethernet/marvell/mvneta.c
#define MVNETA_TX_DONE_TIMER_PERIOD 10
/* Trigger tx done timer in MVNETA_TX_DONE_TIMER_PERIOD msecs */
static void mvneta_add_tx_done_timer(struct mvneta_port *pp)
{
if (test_and_set_bit(MVNETA_F_TX_DONE_TIMER_BIT, &pp->flags) == 0) {
pp->tx_done_timer.expires = jiffies +
msecs_to_jiffies(MVNETA_TX_DONE_TIMER_PERIOD);
add_timer(&pp->tx_done_timer);
}
}
Holding skb 10 ms before TX completion is totally wrong and must be fixed.
If really NIC is not able to trigger an interrupt after TX completion, then
driver should call skb_orphan() in its ndo_start_xmit()
^ permalink raw reply
* Re: [patch net-next 0/2] netfilter: push reasm skb through instead of original frag skbs
From: David Miller @ 2013-11-11 5:47 UTC (permalink / raw)
To: jiri
Cc: netdev, pablo, netfilter-devel, yoshfuji, kadlec, kaber, mleitner,
kuznet, jmorris, wensong, horms, ja, edumazet, pshelar, jasowang,
alexander.h.duyck, fw
In-Reply-To: <1383756740-7392-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 6 Nov 2013 17:52:18 +0100
> Jiri Pirko (2):
> ip6_output: fragment outgoing reassembled skb properly
> netfilter: push reasm skb through instead of original frag skbs
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [patch net-next 1/2] ip6_output: fragment outgoing reassembled skb properly
From: David Miller @ 2013-11-11 5:47 UTC (permalink / raw)
To: jiri
Cc: netdev, pablo, netfilter-devel, yoshfuji, kadlec, kaber, mleitner,
kuznet, jmorris, wensong, horms, ja, edumazet, pshelar, jasowang,
alexander.h.duyck, fw
In-Reply-To: <20131109110053.GA2447@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sat, 9 Nov 2013 12:00:53 +0100
> I hope I cleared this out.
Thanks for the explanation, I see now.
^ permalink raw reply
* Re: [net 2/2] ixgbe: add warning when max_vfs is out of range.
From: David Miller @ 2013-11-11 5:46 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: jacob.e.keller, netdev, gospo, sassmann
In-Reply-To: <1384001552-18754-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 9 Nov 2013 04:52:32 -0800
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> The max_vfs parameter has a limit of 63 and silently fails (adding 0 vfs) when
> it is out of range. This patch adds a warning so that the user knows something
> went wrong. Also, this patch moves the warning in ixgbe_enable_sriov() to where
> max_vfs is checked, so that even an out of range value will show the deprecated
> warning. Previously, an out of range parameter didn't even warn the user to use
> the new sysfs interface instead.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox