* Re: [PATCH] qlcnic: add missing destroy_workqueue() on error path in qlcnic_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: himanshu.madhani, rajesh.borundia, shahed.shaikh,
jitendra.kalsaria, sony.chacko, sucheta.chakraborty, yongjun_wei,
linux-driver, netdev
In-Reply-To: <CAPgLHd9oA08=1o_DWE0SGeg_7nokr3-WPEAOrG71bYg2C1676A@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:32:17 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add the missing destroy_workqueue() before return from
> qlcnic_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] sh_eth: NAPI requires netif_receive_skb()
From: Sergei Shtylyov @ 2013-10-08 21:52 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: David Miller, netdev, nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <Pine.LNX.4.64.1309261751200.11968@axis700.grange>
Hello.
On 26-09-2013 18:12, Guennadi Liakhovetski wrote:
>> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Date: Tue, 3 Sep 2013 03:03:10 +0400
>>> Driver supporting NAPI should use NAPI-specific function for receiving packets,
>>> so netif_rx() should be changed to netif_receive_skb().
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> This patch breaks NFS boot on Armadillo800eva for me. Network
> communication slows down to a crawl with
> net eth0: Receive FIFO Overflow
> nfs: server 192.168.x.y not responding, still trying
> With this patch reverted (e.g. in today's Linus tree snapshot) boot is
> restored.
Guennadi, are you expecting some actions (like looking into what Eric have
suggested) from me? If so, I'm still on vacation, should be back next Tuesday.
I don't think reverting the patch is a Right Thing to do.
> Thanks
> Guennadi
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] moxa: fix the error handling in moxart_mac_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: grant.likely, rob.herring, jg1.han, b.zolnierkie, kyungmin.park,
yongjun_wei, netdev
In-Reply-To: <CAPgLHd95agB+cseQmD4wg50wX_ddyZ0=0VxJ8vAR80ZbcFsMTw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:19:19 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> This patch fix the error handling in moxart_mac_probe():
> - return -ENOMEM in some memory alloc fail cases
> - add missing free_netdev() in the error handling case
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sesse
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 14:44:29 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Steinar reported FQ pacing was not working for UDP flows.
>
> It looks like the initial sk->sk_pacing_rate value of 0 was
> a wrong choice. We should init it to ~0U like sk_max_pacing_rate
>
> Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
> no real sense. (The default rate is really : ~0U)
>
> While debugging this issue, I realized sk_pacing_rate is shared between
> transport and packet scheduler without locking / barriers :
>
> We should use ACCESS_ONCE() to make sure compiler wont perform
> multiple loads or stores.
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Is this meant for net or net-next? It doesn't apply cleanly to the
former.
^ permalink raw reply
* Re: [PATCH] net: vlan: fix nlmsg size calculation in vlan_get_size()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, kaber
In-Reply-To: <1381180798-26654-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 7 Oct 2013 23:19:58 +0200
> This patch fixes the calculation of the nlmsg size, by adding the missing
> nla_total_size().
>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix typo for initial_quantum
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381175418.12191.19.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 12:50:18 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCA_FQ_INITIAL_QUANTUM should set q->initial_quantum
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: Fix the upper MTU limit in GRE tunnel
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: ou.ghorbel; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1381168205-7465-1-git-send-email-ou.ghorbel@gmail.com>
From: Oussama Ghorbel <ou.ghorbel@gmail.com>
Date: Mon, 7 Oct 2013 18:50:05 +0100
> Unlike ipv4, the struct member hlen holds the length of the GRE and ipv6
> headers. This length is also counted in dev->hard_header_len.
> Perhaps, it's more clean to modify the hlen to count only the GRE header
> without ipv6 header as the variable name suggest, but the simple way to fix
> this without regression risk is simply modify the calculation of the limit
> in ip6gre_tunnel_change_mtu function.
> Verified in kernel version v3.11.
>
> Signed-off-by: Oussama Ghorbel <ou.ghorbel@gmail.com>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] cgroup: cls: remove unnecessary task_cls_classid
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: gaofeng-BthXqXjhjHXQFUHtdCDX3A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
jhs-jkUAjuhPggJWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
nhorman-2XuSBdqkA4R54TAoqtyWWQ, lizefan-hv44wF8Li93QT0dZR+AlfA,
daniel.wagner-98C5kh4wR6ohFhg+JK9F0w
In-Reply-To: <1381201520-25938-2-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date: Tue, 8 Oct 2013 11:05:20 +0800
> We can get classid through cgroup_subsys_state,
> this is directviewing and effective.
>
> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] cgroup: netprio: remove unnecessary task_netprioidx
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: gaofeng-BthXqXjhjHXQFUHtdCDX3A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
jhs-jkUAjuhPggJWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
nhorman-2XuSBdqkA4R54TAoqtyWWQ, lizefan-hv44wF8Li93QT0dZR+AlfA,
daniel.wagner-98C5kh4wR6ohFhg+JK9F0w
In-Reply-To: <1381201520-25938-1-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date: Tue, 8 Oct 2013 11:05:19 +0800
> Since the tasks have been migrated to the cgroup,
> there is no need to call task_netprioidx to get
> task's cgroup id.
>
> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] Improve UDP multicast receive latency
From: David Miller @ 2013-10-08 20:51 UTC (permalink / raw)
To: shawn.bohrer; +Cc: netdev, tomk, eric.dumazet, sbohrer
In-Reply-To: <1381161700-14453-1-git-send-email-shawn.bohrer@gmail.com>
From: Shawn Bohrer <shawn.bohrer@gmail.com>
Date: Mon, 7 Oct 2013 11:01:37 -0500
> From: Shawn Bohrer <sbohrer@rgmadvisors.com>
>
> The removal of the routing cache in 3.6 had impacted the latency of our
> UDP multicast workload. This patch series brings down the latency to
> what we were seeing with 3.4.
>
> Patch 1 "udp: Only allow busy read/poll on connected sockets" is mostly
> done for correctness and because it allows unifying the unicast and
> multicast paths when a socket is found in early demux. It can also
> improve latency for a connected multicast socket if busy read/poll is
> used.
>
> Patches 2&3 remove the fib lookups and restore latency for our workload
> to the pre 3.6 levels.
>
> Benchmark results from a netperf UDP_RR test:
> v3.12-rc3-447-g40dc9ab kernel 87961.22 transactions/s
> v3.12-rc3-447-g40dc9ab + series 90587.62 transactions/s
>
> Benchmark results from a fio 1 byte UDP multicast pingpong test
> (Multicast one way unicast response):
> v3.12-rc3-447-g40dc9ab kernel 12.97us RTT
> v3.12-rc3-447-g40dc9ab + series 12.48us RTT
Great work, all applied to net-next, thanks!
^ permalink raw reply
* Re: [PATCH net-next] net_sched: increment drop counters in qdisc_tree_decrease_qlen()
From: David Miller @ 2013-10-08 20:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381159952.12191.14.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 08:32:32 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> qdisc_tree_decrease_qlen() is called when some packets are dropped
> on a qdisc, and we want to notify parents of qlen changes.
>
> We also can increment parents qdisc qstats drop counters.
>
> This permits more accurate drop counters up to root qdisc.
>
> For example a graft operation typically resets a qdisc
> (drops all packets) and call qdisc_tree_decrease_qlen()
>
> Note that callers are responsible for their drop counters.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net V1 0/2] net/mlx4_en: Fix pages never dma unmapped on rx
From: David Miller @ 2013-10-08 20:10 UTC (permalink / raw)
To: amirv; +Cc: netdev, ogerlitz, eugenia, edumazet
In-Reply-To: <1381145893-20930-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Mon, 7 Oct 2013 13:38:11 +0200
> This patchset fixes a bug introduced by commit 51151a16 (mlx4: allow order-0
> memory allocations in RX path). Where dma_unmap_page wasn't called.
>
> Changes from V0:
> - Added "Rename name of mlx4_en_rx_alloc members". Old names were confusing.
> - Last frag in page calculation was wrong. Since all frags in page are of the
> same size, need to add this frag_stride to end of frag offset, and not the
> size of next frag in skb.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bonding: ensure that TLB mode's active slave has correct mac filter
From: David Miller @ 2013-10-08 20:07 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy, yuvalmin
In-Reply-To: <1381130240-3561-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Mon, 7 Oct 2013 09:17:20 +0200
> Currently, in TLB mode we change mac addresses only by memcpy-ing the to
> net_device->dev_addr, without actually setting them via
> dev_set_mac_address(). This permits us to receive all the traffic always on
> one mac address.
>
> However, in case the interface flips, some drivers might enforce the
> mac filtering for its FW/HW based on current ->dev_addr, and thus we won't
> be able to receive traffic on that interface, in case it will be selected
> as active in TLB mode.
>
> Fix it by setting the mac address forcefully on every new active slave that
> we select in TLB mode.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Yuval Mintz <yuvalmin@broadcom.com>
> Reported-by: Yuval Mintz <yuvalmin@broadcom.com>
> Tested-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Since we hole the RTNL during this tricky operation I guess this is fine.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Fix RX packets errors on R8A7740
From: David Miller @ 2013-10-08 20:04 UTC (permalink / raw)
To: nh-ky; +Cc: netdev, ryusuke.sakato.bx, sergei.shtylyov, horms
In-Reply-To: <1381127365-6521-1-git-send-email-nh-ky@jinso.co.jp>
From: Nguyen Hong Ky <nh-ky@jinso.co.jp>
Date: Mon, 7 Oct 2013 15:29:24 +0900
> This patch will fix RX packets errors when receiving big size of data.
> Moreover, I set suitable parameters for get more stable when receiving
> packets.
>
> It was created on the top of mainline kernel v3.11.
>
> I tested this patch on Armadillo800eva, it appears to be working well.
>
> Would you please review and apply it for me.
Applied, but at some point someone has to add definitions for the
RMCR register fields so that this driver is not full of magic constants.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 20:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Patch Tracking, linville
In-Reply-To: <1381259316.13359.17.camel@jlt4.sipsolutions.net>
On 8 October 2013 21:08, Johannes Berg <johannes@sipsolutions.net> wrote:
> I'm not too familiar with the aead API, so here's another question:
>
>> + sg_init_one(&pt, data, data_len);
>> + sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
>> + sg_init_table(ct, 2);
>> + sg_set_buf(&ct[0], cdata, data_len);
>> + sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
>
> Is it guaranteed to be allowed that the input and output are the same
> buffer? It seems we rely on that for encrypt_one(), but is it true here
> as well?
>
Yes, the crypto layer handles all of that without issue.
> (Btw - why pass in data/cdata as separate pointers into the function?)
>
That is just a leftover of the old implementation. I will remove that
in v2, that will cut down the number of function args as well.
>> @@ -343,7 +337,7 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
>> data_len -= IEEE80211_CCMP_MIC_LEN;
>>
>> /* First block, b_0 */
>> - b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
>> + b_0[0] = 0x1; /* set L := 1, M and Adata flags are implied */
>
> Hmm. I don't think I understand, can you explain this to me?
>
Well M is implied by the setauthsize() in init() [M := (MIC_LEN-2)/2
== 3], and the set_assoc() call in en/decrypt() indicates the presence
of assoc (A) data. Instead of setting the flags here, and clearing
them by anding with ~0x7 (as in the old implementation), this lets the
CCM layer handle that.
--
Ard.
^ permalink raw reply
* Re: [PATCH] net: af802154: Fix wrong structure declaration
From: David Miller @ 2013-10-08 19:49 UTC (permalink / raw)
To: linux; +Cc: alex.bluesman.smirnov, dbaryshkov, netdev, linux-zigbee-devel
In-Reply-To: <1381095841-15031-1-git-send-email-linux@roeck-us.net>
From: Guenter Roeck <linux@roeck-us.net>
Date: Sun, 6 Oct 2013 14:44:01 -0700
> net_devce doesn't exist.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This is simply rediculous.
The reason I say this is that every user of this header includes
net/sock.h which in turn includes linux/skbuff.h and linux/netdevice.h
which therefore bring in all the necessary structure definitions.
Really, the most correct change is to make af802154.h explicitly
include those header files.
^ permalink raw reply
* Re: [PATCH] tun: don't look at current when non-blocking
From: David Miller @ 2013-10-08 19:46 UTC (permalink / raw)
To: mst; +Cc: netdev, linux-kernel, jasowang, edumazet, xemul
In-Reply-To: <20131006182512.GA16504@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 6 Oct 2013 21:25:12 +0300
> We play with a wait queue even if socket is
> non blocking. This is an obvious waste.
> Besides, it will prevent calling the non blocking
> variant when current is not valid.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH] l2tp: Fix build warning with ipv6 disabled.
From: David Miller @ 2013-10-08 19:45 UTC (permalink / raw)
To: netdev
net/l2tp/l2tp_core.c: In function ‘l2tp_verify_udp_checksum’:
net/l2tp/l2tp_core.c:499:22: warning: unused variable ‘tunnel’ [-Wunused-variable]
Create a helper "l2tp_tunnel()" to facilitate this, and as a side
effect get rid of a bunch of unnecessary void pointer casts.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/l2tp/l2tp_core.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index aedaa2c..b076e83 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -115,6 +115,11 @@ struct l2tp_net {
static void l2tp_session_set_header_len(struct l2tp_session *session, int version);
static void l2tp_tunnel_free(struct l2tp_tunnel *tunnel);
+static inline struct l2tp_tunnel *l2tp_tunnel(struct sock *sk)
+{
+ return sk->sk_user_data;
+}
+
static inline struct l2tp_net *l2tp_pernet(struct net *net)
{
BUG_ON(!net);
@@ -496,7 +501,6 @@ out:
static inline int l2tp_verify_udp_checksum(struct sock *sk,
struct sk_buff *skb)
{
- struct l2tp_tunnel *tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
__wsum psum;
@@ -505,7 +509,7 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
return 0;
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6 && !tunnel->v4mapped) {
+ if (sk->sk_family == PF_INET6 && !l2tp_tunnel(sk)->v4mapped) {
if (!uh->check) {
LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
return 1;
@@ -1305,10 +1309,9 @@ EXPORT_SYMBOL_GPL(l2tp_xmit_skb);
*/
static void l2tp_tunnel_destruct(struct sock *sk)
{
- struct l2tp_tunnel *tunnel;
+ struct l2tp_tunnel *tunnel = l2tp_tunnel(sk);
struct l2tp_net *pn;
- tunnel = sk->sk_user_data;
if (tunnel == NULL)
goto end;
@@ -1676,7 +1679,7 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
}
/* Check if this socket has already been prepped */
- tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
+ tunnel = l2tp_tunnel(sk);
if (tunnel != NULL) {
/* This socket has already been prepped */
err = -EBUSY;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v1 0/3] Fix race conditions in mrf24j40 interrupts
From: David Miller @ 2013-10-08 19:32 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, david, linux-zigbee-devel,
netdev, linux-kernel
In-Reply-To: <1381031544-2960-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Sat, 5 Oct 2013 23:52:21 -0400
> After testing with the betas of this patchset, it's been rebased and is
> ready for inclusion.
>
> David Hauweele noticed that the mrf24j40 would hang arbitrarily after some
> period of heavy traffic. Two race conditions were discovered, and the
> driver was changed to use threaded interrupts, since the enable/disable of
> interrupts in the driver has recently been a lighning rod whenever issues
> arise related to interrupts (costing engineering time), and since threaded
> interrupts are the right way to do it.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] 6lowpan default hardware address
From: David Miller @ 2013-10-08 19:29 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, alex.aring, linux-zigbee-devel,
netdev, linux-kernel
In-Reply-To: <1381029319-6835-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Sat, 5 Oct 2013 23:15:17 -0400
> Alexander Aring suggested that devices desired to be linked to 6lowpan
> be checked for actually being of type IEEE802154, since IEEE802154 devices
> are all that are supported by 6lowpan at present.
>
> Alan Ott (2):
> 6lowpan: Only make 6lowpan links to IEEE802154 devices
> 6lowpan: Sync default hardware address of lowpan links to their wpan
Series applied, thanks Alan.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: David Miller @ 2013-10-08 19:23 UTC (permalink / raw)
To: yamato; +Cc: netdev
In-Reply-To: <1380854061-30091-1-git-send-email-yamato@redhat.com>
From: Masatake YAMATO <yamato@redhat.com>
Date: Fri, 4 Oct 2013 11:34:21 +0900
> ip link has ability to show extra information of net work device if
> kernel provides sunh information. With this patch veth driver can
> provide its peer ifindex information to ip command via netlink
> interface.
>
> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH net-next] Revert "xen-netback: improve ring effeciency for guest RX"
From: David Miller @ 2013-10-08 19:11 UTC (permalink / raw)
To: ian.campbell
Cc: wei.liu2, netdev, xen-devel, annie.li, msw, xixiong, david.vrabel,
paul.durrant
In-Reply-To: <1381227707.3804.65.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 8 Oct 2013 11:21:47 +0100
> On Tue, 2013-10-08 at 10:54 +0100, Wei Liu wrote:
>> This reverts commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c.
>>
>> The named changeset is causing problem. Let's aim to make this part less
>> fragile before trying to improve things.
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Although I thought davem would just run git revert so I don't know if it
> is needed.
This works too, because it gives you guys an opportunity to add
some explanation to the commit message.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 19:08 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, patches-QSEj5FYQhm4dnm+yROfE0A,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <1381231915-24232-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
I'm not too familiar with the aead API, so here's another question:
> + sg_init_one(&pt, data, data_len);
> + sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
> + sg_init_table(ct, 2);
> + sg_set_buf(&ct[0], cdata, data_len);
> + sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
Is it guaranteed to be allowed that the input and output are the same
buffer? It seems we rely on that for encrypt_one(), but is it true here
as well?
(Btw - why pass in data/cdata as separate pointers into the function?)
> @@ -343,7 +337,7 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
> data_len -= IEEE80211_CCMP_MIC_LEN;
>
> /* First block, b_0 */
> - b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
> + b_0[0] = 0x1; /* set L := 1, M and Adata flags are implied */
Hmm. I don't think I understand, can you explain this to me?
johannes
--
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
* Re: tx checksum offload in rtl8168evl disabled in driver
From: jason.morgan @ 2013-10-08 18:44 UTC (permalink / raw)
To: Francois Romieu; +Cc: Hayes Wang, netdev
In-Reply-To: <20131005092252.GA23084@electric-eye.fr.zoreil.com>
>
> (please don't top post)
Sorry, I was not aware of the correct netiquette
replies now inline.
>
> jason.morgan@....> :
> > Ubuntu 12.04.3 LTS + Kernel 3.8.13-8 64bit
> >
> > I've patched the driver to allow tx checksum offload for this chip and
> > found the following:
> >
> > MTU 9000 standard driver:
> > 517Mbps with 2k + header frames
> >
> > MTU 9000 patched driver:
> > 770Mbps with 2k + header frames
> >
> > 100% transfer without error (1e6 frames)
>
> (Ok, so that's 20 ~ 30s worth of traffic)
Right now this is representative as the network has no other traffic and
the CPU has no other function.
I will be producing hours of traffic soon in a more realistic network, see
later....
>
> > 48% increase in performance combined with a massive decrease in CPU
> > effort is not to be sniffed at.
>
> *sniff* :o)
Drums.... BurrDumpf!
>
> It depends on the CPU. You did not specify it and you did not give
numbers
> for the decrease (did you use 'perf' btw ?). They would be welcome.
As I've patched the kernel driver and build a new kernel, I have no idea
how to build a perf for my installed kernel.
It appears that there is not one pre-built.
Any help here?
When I learn how to build perf I can reply with CPU performance data.
>
> > IMO tx offload should be more prevalent as the frames grow, to reduce
> > CPU load.
>
> I can't disagree.
>
> > OK, so make the default OFF if there is a silicon error (that spans
> > mulitple chips?),
>
> Yes, I want safe defaults for the kernel.
Safe defaults are of course a good thing.
Others have stated that this is not a silicon error, it's a hardware
feature which it appears
the Linux default for which is non-optimal and there is no means (bar
hacking) to optimise it.
>
> I give the manufacturer's explanations a lot of credit when they're
> related to hardware (up to the point where the marketing or legal dept
> kicks in). If we want to balance these with experimental evidences, the
> latter must be really, really strong.
To me it appears the latency stats ( a marketing metric of the MAC )
somehow outweigh the load on the CPU
( which is factored out of MAC stats ) so perhaps your comment on the
marketing dept rings true?
Are there any tests that you can suggest that would provide such evidence?
I am in the process of building a LAN of 18 machines with the intent of
saturating a 1G/10G Ethernet switch, so I have a good test platform - for
one chip anyway.
>
> > but why prevent it being turned on in the driver?
> > even if there is a kernel message that this might cause problems.
>
> Two points:
> - it's a hack: ethtool will return success. A kernel message is not a
> substitute for "Yes, I opt in for problems".
> - we can't tell when it's safe and when it isn't.
I would agree that generally ethtool can't be trusted, but it is clear
that
it does work with this driver for this chip for this control so in that
case surely it can be trusted?
The statement "we can't tell when it's safe and when it isn't." is true
for almost any hardware interface
Usually we offer safe defaults and a means to trade off safety and
performance, though that is not always the case, e.g.
It's much safer to run DDR3-1600 as DDR3-1066, but if that were the
default people would complain.
>
> --
> Ueimor
> --
> 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] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 18:27 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: David Laight,
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
<linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
In-Reply-To: <CAKv+Gu8D_7d=u1PGWuxoLEETHe8uJMby3K98uQWQn7tk=t_t_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2013-10-08 at 16:52 +0200, Ard Biesheuvel wrote:
> However, personally I don't think this should be necessary and in fact
> my patch removes a stack allocation of u8[48] (from
> ieee80211_crypto_ccmp_decrypt() and from ccmp_encrypt_skb() in wpa.c)
> so it does even out a bit.
I tend to agree.
johannes
--
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
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