* 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
* Re: IPv6 kernel warning
From: dormando @ 2013-10-08 18:24 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Michele Baldessari, Russell King - ARM Linux, netdev,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <CAK6E8=d_O+HHTKb37zGKxpU8E0tTUL6m77g_o6a7ASEiJfXSkw@mail.gmail.com>
On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> On Mon, Oct 7, 2013 at 12:56 PM, dormando <dormando@rydia.net> wrote:
> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> >
> >> On Mon, Oct 7, 2013 at 11:13 AM, dormando <dormando@rydia.net> wrote:
> >> >
> >> > > >
> >> > > > there's been multiple reports about this one:
> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=989251
> >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=60779
> >> > > >
> >> > > > Could you try Yuchung's debug patch?
> >> > > > http://www.spinics.net/lists/netdev/msg250193.html
> >> > > Yes it looks like the same bug. Please try that patch to help identify
> >> > > this elusive bug.
> >> > >
> >> >
> >> > Hi!
> >> >
> >> > We get this one a few times a day in production. Here's a warning with
> >> > your debug trace in the line immediately following:
> >> > (I censored a few things)
> >> >
> >> > [125311.721950] ------------[ cut here ]------------
> >> > [125311.721961] WARNING: at net/ipv4/tcp_input.c:2776 tcp_fastretrans_alert+0xb58/0xc80()
> >> > [125311.721962] Modules linked in: bridge ip_vs macvlan coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog microcode ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si ipmi_msghandler iptable_nat nf_nat_ipv4 nf_nat ixgbe igb mdio i2c_algo_bit ptp pps_core
> >> > [125311.721981] CPU: 11 PID: 0 Comm: swapper/11 Not tainted 3.10.13 #1
> >> > [125311.721982] Hardware name: Supermicro XXXXXXXXXXX, BIOS 1.1 10/03/2012
> >> > [125311.721984] ffffffff81a82007 ffff88407fc63958 ffffffff816bb9cc ffff88407fc63998
> >> > [125311.721986] ffffffff8104b940 00ff8840ad904f82 ffff883b8a165b00 0000000000004120
> >> > [125311.721989] 0000000000000001 0000000000000019 0000000000000000 ffff88407fc639a8
> >> > [125311.721991] Call Trace:
> >> > [125311.721992] <IRQ> [<ffffffff816bb9cc>] dump_stack+0x19/0x1d
> >> > [125311.722002] [<ffffffff8104b940>] warn_slowpath_common+0x70/0xa0
> >> > [125311.722005] [<ffffffff8104b98a>] warn_slowpath_null+0x1a/0x20
> >> > [125311.722007] [<ffffffff81616db8>] tcp_fastretrans_alert+0xb58/0xc80
> >> > [125311.722011] [<ffffffff8161891f>] tcp_ack+0x6df/0xe90
> >> > [125311.722016] [<ffffffff8164e0ca>] ? ipt_do_table+0x22a/0x680
> >> > [125311.722018] [<ffffffff816194b3>] ? tcp_validate_incoming+0x63/0x320
> >> > [125311.722021] [<ffffffff8161a55c>] tcp_rcv_established+0x2cc/0x810
> >> > [125311.722023] [<ffffffff81622c84>] tcp_v4_do_rcv+0x254/0x4f0
> >> > [125311.722025] [<ffffffff816245ac>] tcp_v4_rcv+0x5fc/0x750
> >> > [125311.722027] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> >> > [125311.722032] [<ffffffff815df3ad>] ? nf_hook_slow+0x7d/0x160
> >> > [125311.722034] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> >> > [125311.722036] [<ffffffff815fface>] ip_local_deliver_finish+0xce/0x250
> >> > [125311.722037] [<ffffffff815ffc9c>] ip_local_deliver+0x4c/0x80
> >> > [125311.722039] [<ffffffff815ff329>] ip_rcv_finish+0x119/0x360
> >> > [125311.722040] [<ffffffff815ff8e0>] ip_rcv+0x230/0x350
> >> > [125311.722046] [<ffffffff815b4067>] __netif_receive_skb_core+0x477/0x600
> >> > [125311.722049] [<ffffffff815b4217>] __netif_receive_skb+0x27/0x70
> >> > [125311.722051] [<ffffffff815b4354>] process_backlog+0xf4/0x1e0
> >> > [125311.722053] [<ffffffff815b4b45>] net_rx_action+0xf5/0x250
> >> > [125311.722056] [<ffffffff81053a5f>] __do_softirq+0xef/0x270
> >> > [125311.722058] [<ffffffff81053cb5>] irq_exit+0x95/0xa0
> >> > [125311.722062] [<ffffffff816c8f26>] do_IRQ+0x66/0xe0
> >> > [125311.722065] [<ffffffff816bf62a>] common_interrupt+0x6a/0x6a
> >> > [125311.722065] <EOI> [<ffffffff8100abf1>] ? default_idle+0x21/0xc0
> >> > [125311.722082] [<ffffffff8100a54f>] arch_cpu_idle+0xf/0x20
> >> > [125311.722086] [<ffffffff8108f353>] cpu_startup_entry+0xb3/0x230
> >> > [125311.722091] [<ffffffff816b439e>] start_secondary+0x1dc/0x1e3
> >> > [125311.722093] ---[ end trace e77cd5ba583fcbe9 ]---
> >> > [125311.722096] 355.355.1.355:22496 F0x4120 S1 s7 IF25+17-1-24f0 ur57 rr3 rt0 um0 hs23120 nxt23120
> >> >
> >> > It's been happening with all 3.10 kernels, and the one above is .13 as
> >> > stated in the trace.
> >>
> >> Thanks! could you post the output of `sysctl -a |grep tcp`?
> >>
> >> I suspect tcp_process_tlp_ack() should not revert state to Open
> >> directly, but calling tcp_try_keep_open() instead, similar to all the
> >> undo processing in the tcp_fastretrans_alert(): after
> >> tcp_end_cwnd_reduction(), the process (E) falls back to check other
> >> stats before moving to CA_Open.
> >>
> >>
> >> index 9c62257..9012b42 100644
> >> --- a/net/ipv4/tcp_input.c
> >> +++ b/net/ipv4/tcp_input.c
> >> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
> >> tcp_init_cwnd_reduction(sk, true);
> >> tcp_set_ca_state(sk, TCP_CA_CWR);
> >> tcp_end_cwnd_reduction(sk);
> >> - tcp_set_ca_state(sk, TCP_CA_Open);
> >> + tcp_try_keep_open(sk);
> >> NET_INC_STATS_BH(sock_net(sk),
> >> LINUX_MIB_TCPLOSSPROBERECOVERY);
> >> }
> >>
> >
> > Should I apply this and see if the warning stops?
> I'd like to hear what the authors of TLP think. In the mean time could
> you help us collect more evidence by disabling TLP with
> sysctl net.ipv4.tcp_early_retrans=2
> and see if the problem still occurs? (it should not).
>
> thanks
Box hasn't had a warning in the last 24ish hours. A neighboring machine
with the default tcp_early_retrans setting has had 5-6 in the same
timeframe.
Is this a harmful situation to the socket in any way, or is it just
informational weirdness?
^ permalink raw reply
* Re: IPv6 kernel warning
From: Yuchung Cheng @ 2013-10-08 17:56 UTC (permalink / raw)
To: Neal Cardwell
Cc: dormando, Michele Baldessari, Russell King - ARM Linux, netdev,
Nandita Dukkipati
In-Reply-To: <CADVnQynJVvFesFYp68N5kzCJJD3-NXPZUUMfkg8m=or4eaLzMQ@mail.gmail.com>
On Tue, Oct 8, 2013 at 7:05 AM, Neal Cardwell <ncardwell@google.com> wrote:
> On Mon, Oct 7, 2013 at 3:51 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> I suspect tcp_process_tlp_ack() should not revert state to Open
>> directly, but calling tcp_try_keep_open() instead, similar to all the
>> undo processing in the tcp_fastretrans_alert(): after
>> tcp_end_cwnd_reduction(), the process (E) falls back to check other
>> stats before moving to CA_Open.
>>
>>
>> index 9c62257..9012b42 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
>> tcp_init_cwnd_reduction(sk, true);
>> tcp_set_ca_state(sk, TCP_CA_CWR);
>> tcp_end_cwnd_reduction(sk);
>> - tcp_set_ca_state(sk, TCP_CA_Open);
>> + tcp_try_keep_open(sk);
>> NET_INC_STATS_BH(sock_net(sk),
>> LINUX_MIB_TCPLOSSPROBERECOVERY);
>> }
>
> Yes, nice catch! This looks good to me. My testing confirms that this
> definitely fixes a bug when this code fires and there are segments
> SACKed out. Since it will stay in CA_Disorder if there are outstanding
> retransmissions, I bet it will also fix the WARN_ON(tp->retrans_out !=
> 0) in state TCP_CA_Open that people are seeing.
Sounds good. Let me do more tests then I will submit a bug fix.
>
> neal
^ permalink raw reply
* [PATCH 1/3] net: bpf jit: ppc: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-08 16:31 UTC (permalink / raw)
To: netdev
Cc: av1474, Vladimir Murzin, Jan Seiffert, Benjamin Herrenschmidt,
Paul Mackerras, Daniel Borkmann, Matt Evans
Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
were not passed. At the same time handlers for "any offset" cases make
the same checks against r_addr at run-time, that will always lead to
bpf_error.
Run-time checks are still necessary for indirect load operations, but
error path for absolute and mesh loads are worth to optimize during bpf
compile time.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Cc: Jan Seiffert <kaffeemonster@googlemail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Daniel Borkmann <dborkman@redhat.com>
Cc: Matt Evans <matt@ozlabs.org>
---
arch/powerpc/net/bpf_jit_comp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index bf56e33..754320a 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -132,7 +132,7 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Assemble the body code between the prologue & epilogue. */
static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
@@ -427,6 +427,11 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
case BPF_S_LD_B_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
common_load:
+ if (!func) {
+ PPC_LI(r_ret, 0);
+ PPC_JMP(exit_addr);
+ break;
+ }
/* Load from [K]. */
ctx->seen |= SEEN_DATAREF;
PPC_LI64(r_scratch1, func);
--
1.7.10.4
^ permalink raw reply related
* [PATCH net 6/6] sfc: Only bind to EF10 functions with the LinkCtrl and Trusted flags
From: Ben Hutchings @ 2013-10-08 17:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1381254091.1530.9.camel@bwh-desktop.uk.level5networks.com>
Although we do not yet enable multiple PFs per port, it is possible
that a board will be reconfigured to enable them while the driver has
not yet been updated to fully support this.
The most obvious problem is that multiple functions may try to set
conflicting link settings. But we will also run into trouble if the
firmware doesn't consider us fully trusted. So, abort probing unless
both the LinkCtrl and Trusted flags are set for this function.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/mcdi.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/mcdi.c b/drivers/net/ethernet/sfc/mcdi.c
index c082562..366c8e3 100644
--- a/drivers/net/ethernet/sfc/mcdi.c
+++ b/drivers/net/ethernet/sfc/mcdi.c
@@ -963,7 +963,7 @@ static int efx_mcdi_drv_attach(struct efx_nic *efx, bool driver_operating,
bool *was_attached)
{
MCDI_DECLARE_BUF(inbuf, MC_CMD_DRV_ATTACH_IN_LEN);
- MCDI_DECLARE_BUF(outbuf, MC_CMD_DRV_ATTACH_OUT_LEN);
+ MCDI_DECLARE_BUF(outbuf, MC_CMD_DRV_ATTACH_EXT_OUT_LEN);
size_t outlen;
int rc;
@@ -981,6 +981,22 @@ static int efx_mcdi_drv_attach(struct efx_nic *efx, bool driver_operating,
goto fail;
}
+ /* We currently assume we have control of the external link
+ * and are completely trusted by firmware. Abort probing
+ * if that's not true for this function.
+ */
+ if (driver_operating &&
+ outlen >= MC_CMD_DRV_ATTACH_EXT_OUT_LEN &&
+ (MCDI_DWORD(outbuf, DRV_ATTACH_EXT_OUT_FUNC_FLAGS) &
+ (1 << MC_CMD_DRV_ATTACH_EXT_OUT_FLAG_LINKCTRL |
+ 1 << MC_CMD_DRV_ATTACH_EXT_OUT_FLAG_TRUSTED)) !=
+ (1 << MC_CMD_DRV_ATTACH_EXT_OUT_FLAG_LINKCTRL |
+ 1 << MC_CMD_DRV_ATTACH_EXT_OUT_FLAG_TRUSTED)) {
+ netif_err(efx, probe, efx->net_dev,
+ "This driver version only supports one function per port\n");
+ return -ENODEV;
+ }
+
if (was_attached != NULL)
*was_attached = MCDI_DWORD(outbuf, DRV_ATTACH_OUT_OLD_STATE);
return 0;
--
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 related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox