* Re: [PATCH net] ip_tunnel: Don't allow to add the same tunnel multiple times.
From: David Miller @ 2014-09-26 4:43 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <20140923113051.GZ6390@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 23 Sep 2014 13:30:51 +0200
> On Mon, Sep 22, 2014 at 04:45:56PM -0400, David Miller wrote:
>> From: Steffen Klassert <steffen.klassert@secunet.com>
>> Date: Mon, 22 Sep 2014 09:11:08 +0200
>>
>> > When we try to add an already existing tunnel, we don't return
>> > an error. Instead we continue and call ip_tunnel_update().
>> > This means that we can change existing tunnels by adding
>> > the same tunnel multiple times. It is even possible to change
>> > the tunnel endpoints of the fallback device.
>> >
>> > We fix this by returning an error if we try to add an existing
>> > tunnel.
>> >
>> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>> > ---
>> >
>> > I was not able to find a commit that introduced this bug.
>> > Looks like ipip and ip_gre had similar bugs already with
>> > the initial git commit.
>>
>> I'm not so sure about this, perhaps the behavior of being able to
>> change a configuration using an ADD call is intentional?
>
> Hm, I don't think so. Initially it was the same like with ipv6.
> It was possible to add the same tunnel muliple times without
> getting an error, no config change was made. The possibilty
> to change the configuration by adding the same tunnel a second
> time came with the tunnel code unification.
Ok, makes sense. Applied, thanks Steffen.
If I had a euro for every regression introduced by that tunnel
unification patch set I'd be a rich man indeed :-/
^ permalink raw reply
* Re: [PATCH v14 net-next 10/11] bpf: verifier (add verifier core)
From: David Miller @ 2014-09-26 4:40 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
luto-kltTT9wpgjJwATOyAt5JVQ, dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
chema-hpIqsD4AKlfQT0dZR+AlfA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw, pablo-Cap9r6Oaw4JrovVCs/uTlw,
hpa-YMNOUZJC4hwAvxtiuMwx3w, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
keescook-F7+t8E8rja9g9hUCZPvPmw, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1411344411-3824-11-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Sun, 21 Sep 2014 17:06:50 -0700
> +#define _(OP) ({ int ret = (OP); if (ret < 0) return ret; })
Please do not hide program control flow inside of a macro.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/9] ipv6: fib6: socket dst_entry improvments and cleanups
From: David Miller @ 2014-09-26 4:28 UTC (permalink / raw)
To: hannes; +Cc: netdev, eric.dumazet, hideaki, vyasevich, nicolas.dichtel, kafai
In-Reply-To: <cover.1411308211.git.hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 21 Sep 2014 16:11:44 +0200
> Eric Dumazet noticed that rt6_nodes wich are neither RTF_NONEXTHOP nor
> RTF_GATEWAY but DST_HOST ones cause major routing lookup churn because
> their rt6_genid is never renewed, thus ip6_dst_check always considers
> them outdated. This is a major problem, because these kind of routes
> are normally used to in input handling.
This series is a disappointment for me from the perspective of the
fact that we have a regression in mainline and this is too complex
of a set of changes for there.
If we relookup the thing every TCP input packet, we might as well
not do the input route caching in the socket.
^ permalink raw reply
* Re: [PATCH net-next] net: sched: use pinned timers
From: David Miller @ 2014-09-26 4:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1411261290.26859.103.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 20 Sep 2014 18:01:30 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While using a MQ + NETEM setup, I had confirmation that the default
> timer migration ( /proc/sys/kernel/timer_migration ) is killing us.
>
> Installing this on a receiver side of a TCP_STREAM test, (NIC has 8 TX
> queues) :
...
> We can see that timers get migrated into a single cpu, presumably idle
> at the time timers are set up.
> Then all qdisc dequeues run from this cpu and huge lock contention
> happens. This single cpu is stuck in softirq mode and cannot dequeue
> fast enough.
>
> 39.24% [kernel] [k] _raw_spin_lock
> 2.65% [kernel] [k] netem_enqueue
> 1.80% [kernel] [k] netem_dequeue
> 1.63% [kernel] [k] copy_user_enhanced_fast_string
> 1.45% [kernel] [k] _raw_spin_lock_bh
>
> By pinning qdisc timers on the cpu running the qdisc, we respect proper
> XPS setting and remove this lock contention.
>
> 5.84% [kernel] [k] netem_enqueue
> 4.83% [kernel] [k] _raw_spin_lock
> 2.92% [kernel] [k] copy_user_enhanced_fast_string
>
> Current Qdiscs that benefit from this change are :
>
> netem, cbq, fq, hfsc, tbf, htb.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks great, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: Eliminate gso_send_check
From: David Miller @ 2014-09-26 4:23 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <1411249950-6795-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Sat, 20 Sep 2014 14:52:27 -0700
> gso_send_check presents a lot of complexity for what it is being used
> for. It seems that there are only two cases where it might be effective:
> TCP and UFO paths. In these cases, the gso_send_check function
> initializes the TCP or UDP checksum respectively to the pseudo header
> checksum so that the checksum computation is appropriately offloaded or
> computed in the gso_segment functions. The gso_send_check functions
> are only called from dev.c in skb_mac_gso_segment when ip_summed !=
> CHECKSUM_PARTIAL (which seems very unlikely in TCP case). We can move
> the logic of this into the respective gso_segment functions where the
> checksum is initialized if ip_summed != CHECKSUM_PARTIAL.
>
> With the above cases handled, gso_send_check is no longer needed, so
> we can remove all uses of it and the fields in the offload callbacks.
> With this change, ip_summed in the skb should be preserved though all
> the layers of gso_segment calls.
>
> In follow-on patches, we may be able to remove the check setup code in
> tcp_gso_segment if we can guarantee that ip_summed will always be
> CHECKSUM_PARTIAL (verify all paths and probably add an assert in
> tcp_gro_segment).
>
> Tested these patches by:
> - netperf TCP_STREAM test with GSO enabled
> - Forced ip_summed != CHECKSUM_PARTIAL with above
> - Ran UDP_RR with 10000 request size over GRE tunnel. This exercised
> UFO path.
Series applied, thanks Tom.
^ permalink raw reply
* Re: net: stmmac glue layer for Amlogic Meson SoCs
From: David Miller @ 2014-09-26 4:13 UTC (permalink / raw)
To: b.galvani
Cc: netdev, peppe.cavallaro, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, carlo, jerry.cao, victor.wan, linux-kernel,
devicetree
In-Reply-To: <1411219757-9201-1-git-send-email-b.galvani@gmail.com>
From: Beniamino Galvani <b.galvani@gmail.com>
Date: Sat, 20 Sep 2014 15:29:15 +0200
>
> the Ethernet controller available in Amlogic Meson6 and Meson8 SoCs is
> a Synopsys DesignWare MAC IP core, already supported by the stmmac
> driver.
>
> These patches add a glue layer to the driver for the platform-specific
> settings required by the Amlogic variant.
>
> This has been tested on a Amlogic S802 device with the initial Meson
> support submitted by Carlo Caione [1].
>
> [1] http://lwn.net/Articles/612000/
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns
From: Cong Wang @ 2014-09-26 2:09 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andy Lutomirski, Stephen Hemminger, Eric W. Biederman,
linux-api-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, David Miller
In-Reply-To: <5423D80B.9060500-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Thu, Sep 25, 2014 at 1:53 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Le 24/09/2014 18:45, Cong Wang a écrit :
>>
>> On Wed, Sep 24, 2014 at 9:27 AM, Nicolas Dichtel
>> <nicolas.dichtel@6wind.com> wrote:
>>>
>>> Now informations got with 'ip link' are wrong and incomplete:
>>> - the link dev is now tunl0 instead of eth0, because we only got an
>>> ifindex
>>> from the kernel without any netns informations.
>>
>>
>> This is not new, macvlan has the same problem. This is why I said
>> it is mostly a display problem, maybe just mark the ifindex as -1 or
>> something when it is not in this netns. At least I don't expect the inner
>> netns know anything outside, and I don't think I am the only one using
>> netns in this way.
>
> I understand your point but there is several use of netns. Netns can be used
> also to instantiate virtual routers. In this case, administrators or daemons
> need to be able to monitor and dump the configuration on all netns
> (particularly beeing able to identify fully x-netns interfaces). We start to
> discuss this in one of the two thread pointed in my cover letter and get the
> conclusion that checking user ns is a good way to know if an id should be
> disclosed or not for a peer netns.
Then you are leaking information, this breaks isolation.
> Can you describe your use case?
Yes, too simple: isolation networking, different netns's don't see each other
(including anything inside) and only communicate via veth.
> If you only play with netns, you may want to monitor all activies in all
> netns
> (this is already possible) and beeing able to link information between netns
> (this is what I'm trying to solve).
No, I don't want to monitor anything. Even if I wanted, I would just start one
daemon in each netns instead of one for all.
On the other hand, why not exchange the configuration via veth
between different netns? There are many ways to do so with TCP HTTP etc.
This doesn't have to be solved in kernel.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns
From: Cong Wang @ 2014-09-26 1:58 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andy Lutomirski, Stephen Hemminger, Eric W. Biederman,
linux-api-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, David Miller
In-Reply-To: <5423D808.7050800-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Thu, Sep 25, 2014 at 1:53 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Le 24/09/2014 18:48, Cong Wang a écrit :
>
>> On Wed, Sep 24, 2014 at 9:31 AM, Nicolas Dichtel
>> <nicolas.dichtel@6wind.com> wrote:
>>>>
>>>> I think in this case your ID's are still available, but aren't you
>>>> providing a new way
>>>> for the inner netns device to escape which we are trying to avoid?
>>>
>>>
>>> It's why the ids depend on user ns. Only if user ns are the same we allow
>>> to
>>> get an id for a peer netns.
>>
>>
>> Too late, userns is relatively new, relying on it breaks our existing
>> assumption.
>>
> I don't get your point. netns has been added in kernel after user ns:
> acce292c82d4 user namespace: add the framework => 2.6.23
> 5f256becd868 [NET]: Basic network namespace infrastructure. => 2.6.24
Was it complete on 2.6.x? I doubt...
https://lkml.org/lkml/2014/8/20/826
As at Linux 3.8, most relevant subsystems supported user names‐
paces, but a number of filesystems did not have the infrastruc‐
ture needed to map user and group IDs between user namespaces.
Linux 3.9 added the required infrastructure support for many of
the remaining unsupported filesystems (Plan 9 (9P), Andrew File
System (AFS), Ceph, CIFS, CODA, NFS, and OCFS2). Linux 3.11
added support the last of the unsupported major filesystems, XFS.
>
> In the kernel, each netns is linked with a user ns.
Are you saying every time we create a netns we have a new userns?
This doesn't make sense for me.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [RFC PATCH net-next] net: pktgen: packet bursting via skb->xmit_more
From: Eric Dumazet @ 2014-09-26 1:20 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Jesper Dangaard Brouer, Eric Dumazet,
John Fastabend, netdev
In-Reply-To: <1411692382-8898-1-git-send-email-ast@plumgrid.com>
On Thu, 2014-09-25 at 17:46 -0700, Alexei Starovoitov wrote:
> This patch demonstrates the effect of delaying update of HW tailptr.
> (based on earlier patch by Jesper)
>
> burst=1 is a default. It sends one packet with xmit_more=false
> burst=2 sends one packet with xmit_more=true and
> 2nd copy of the same packet with xmit_more=false
> burst=3 sends two copies of the same packet with xmit_more=true and
> 3rd copy with xmit_more=false
>
> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
> ---
Perfect, this is what I had in mind, thanks !
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* [RFC PATCH net-next] net: pktgen: packet bursting via skb->xmit_more
From: Alexei Starovoitov @ 2014-09-26 0:46 UTC (permalink / raw)
To: David S. Miller
Cc: Jesper Dangaard Brouer, Eric Dumazet, John Fastabend, netdev
This patch demonstrates the effect of delaying update of HW tailptr.
(based on earlier patch by Jesper)
burst=1 is a default. It sends one packet with xmit_more=false
burst=2 sends one packet with xmit_more=true and
2nd copy of the same packet with xmit_more=false
burst=3 sends two copies of the same packet with xmit_more=true and
3rd copy with xmit_more=false
Performance with ixgbe:
usec 30:
burst=1 tx:9.2 Mpps
burst=2 tx:13.6 Mpps
burst=3 tx:14.5 Mpps full 10G line rate
usec 1 (default):
burst=1,4,100 tx:3.9 Mpps
usec 0:
burst=1 tx:4.9 Mpps
burst=2 tx:6.6 Mpps
burst=3 tx:7.9 Mpps
burst=4 tx:8.7 Mpps
burst=8 tx:10.3 Mpps
burst=128 tx:12.4 Mpps
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
tx queue size, irq affinity left in default.
pause frames are off.
Nice to finally see line rate generated by one cpu
Comparing to Jesper patch this one amortizes the cost
of spin_lock and atomic_inc by doing HARD_TX_LOCK and
atomic_add(N) once across N packets.
net/core/pktgen.c | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 5c728aa..47557ba 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -387,6 +387,7 @@ struct pktgen_dev {
u16 queue_map_min;
u16 queue_map_max;
__u32 skb_priority; /* skb priority field */
+ int burst; /* number of duplicated packets to burst */
int node; /* Memory node */
#ifdef CONFIG_XFRM
@@ -613,6 +614,9 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
if (pkt_dev->traffic_class)
seq_printf(seq, " traffic_class: 0x%02x\n", pkt_dev->traffic_class);
+ if (pkt_dev->burst > 1)
+ seq_printf(seq, " burst: %d\n", pkt_dev->burst);
+
if (pkt_dev->node >= 0)
seq_printf(seq, " node: %d\n", pkt_dev->node);
@@ -1124,6 +1128,16 @@ static ssize_t pktgen_if_write(struct file *file,
pkt_dev->dst_mac_count);
return count;
}
+ if (!strcmp(name, "burst")) {
+ len = num_arg(&user_buffer[i], 10, &value);
+ if (len < 0)
+ return len;
+
+ i += len;
+ pkt_dev->burst = value < 1 ? 1 : value;
+ sprintf(pg_result, "OK: burst=%d", pkt_dev->burst);
+ return count;
+ }
if (!strcmp(name, "node")) {
len = num_arg(&user_buffer[i], 10, &value);
if (len < 0)
@@ -3299,7 +3313,8 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
{
struct net_device *odev = pkt_dev->odev;
struct netdev_queue *txq;
- int ret;
+ int burst_cnt, ret;
+ bool more;
/* If device is offline, then don't send */
if (unlikely(!netif_running(odev) || !netif_carrier_ok(odev))) {
@@ -3347,8 +3362,14 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
pkt_dev->last_ok = 0;
goto unlock;
}
- atomic_inc(&(pkt_dev->skb->users));
- ret = netdev_start_xmit(pkt_dev->skb, odev, txq, false);
+ atomic_add(pkt_dev->burst, &pkt_dev->skb->users);
+
+ burst_cnt = 0;
+
+xmit_more:
+ more = ++burst_cnt < pkt_dev->burst;
+
+ ret = netdev_start_xmit(pkt_dev->skb, odev, txq, more);
switch (ret) {
case NETDEV_TX_OK:
@@ -3356,6 +3377,8 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
pkt_dev->sofar++;
pkt_dev->seq_num++;
pkt_dev->tx_bytes += pkt_dev->last_pkt_size;
+ if (more)
+ goto xmit_more;
break;
case NET_XMIT_DROP:
case NET_XMIT_CN:
@@ -3374,6 +3397,9 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
atomic_dec(&(pkt_dev->skb->users));
pkt_dev->last_ok = 0;
}
+
+ if (unlikely(pkt_dev->burst - burst_cnt > 0))
+ atomic_sub(pkt_dev->burst - burst_cnt, &pkt_dev->skb->users);
unlock:
HARD_TX_UNLOCK(odev, txq);
@@ -3572,6 +3598,7 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
pkt_dev->svlan_p = 0;
pkt_dev->svlan_cfi = 0;
pkt_dev->svlan_id = 0xffff;
+ pkt_dev->burst = 1;
pkt_dev->node = -1;
err = pktgen_setup_dev(t->net, pkt_dev, ifname);
--
1.7.9.5
^ permalink raw reply related
* Re: [Patch net-next 1/2] net_sched: fix errno in tcindex_set_parms()
From: John Fastabend @ 2014-09-26 0:27 UTC (permalink / raw)
To: John Fastabend; +Cc: Cong Wang, netdev, davem
In-Reply-To: <54249DD9.5060403@gmail.com>
On 09/25/2014 03:57 PM, John Fastabend wrote:
> On 09/25/2014 02:07 PM, John Fastabend wrote:
>> On 09/25/2014 12:06 PM, Cong Wang wrote:
>>> When kmemdup() fails, we should return -ENOMEM.
>>>
>>> Cc: John Fastabend <john.fastabend@gmail.com>
>>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>>> ---
>>
>> Acked-by: John Fastabend <john.r.fastabend@intel.com>
>>
>> Thanks Cong.
>>
>
> Related to this we should probably push error messages
> from the dump routines correctly. If you see u32_dump()
> returns a -EINVAL even though it was due to a memory
> allocation failure. This is not necessarily due to my
> patches though I think the error returning from dump
> has always been a simple -1 value.
>
> I'll take a look at it, unless you beat me to it, after
> I finish up the percpu stats which I'm doing now.
>
> .John
>
Also just in case you hit them, there is an suspicious
rcu usage from qdisc_watchdog and another from task_csl_state()
call in cls_cgroup.
The qdisc_watchdog is due to the annotation on the qdisc
and I'm not entirely convinced the cls_cgroup hasn't been
there all along.
I'm looking into them but most likely wont figure it out
tonight as I have to take off for a bit.
Thanks,
John
^ permalink raw reply
* Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Eric Dumazet @ 2014-09-25 23:40 UTC (permalink / raw)
To: Tom Herbert
Cc: Jesper Dangaard Brouer, Linux Netdev List, David S. Miller,
Alexander Duyck, Toke Høiland-Jørgensen,
Florian Westphal, Jamal Hadi Salim, Dave Taht, John Fastabend,
Daniel Borkmann, Hannes Frederic Sowa
In-Reply-To: <1411611140.16953.1.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 2014-09-24 at 19:12 -0700, Eric Dumazet wrote:
> On Wed, 2014-09-24 at 12:22 -0700, Eric Dumazet wrote:
> > On Wed, 2014-09-24 at 11:34 -0700, Tom Herbert wrote:
> > > >
> > > I believe drivers typically use skb->len for BQL tracking. Since
> > > bytelimit is based on BQL here, it might be more correct to use
> > > skb->len.
>
> Speaking of BQL, I wonder if we now should try to not wakeup queues as
> soon some room was made, and instead have a 50% threshold ?
>
> This would probably increase probability to have bulk dequeues ;)
It turned out the problem I noticed was caused by compiler trying to be
smart, but involving a bad MESI transaction.
0.05 │ mov 0xc0(%rax),%edi // LOAD dql->num_queued
0.48 │ mov %edx,0xc8(%rax) // STORE dql->last_obj_cnt = count
58.23 │ add %edx,%edi
0.58 │ cmp %edi,0xc4(%rax)
0.76 │ mov %edi,0xc0(%rax) // STORE dql->num_queued += count
0.72 │ js bd8
I get an incredible 10 % gain by making sure cpu wont get the cache line
in Shared mode.
(I also tried a barrier() in netdev_tx_sent_queue() between the
dql_queued(&dev_queue->dql, bytes);
-
+ barrier();
if (likely(dql_avail(&dev_queue->dql) >= 0))
But following patch seems cleaner
diff --git a/include/linux/dynamic_queue_limits.h b/include/linux/dynamic_queue_limits.h
index 5621547d631b..978fbe332090 100644
--- a/include/linux/dynamic_queue_limits.h
+++ b/include/linux/dynamic_queue_limits.h
@@ -80,7 +80,7 @@ static inline void dql_queued(struct dql *dql, unsigned int count)
/* Returns how many objects can be queued, < 0 indicates over limit. */
static inline int dql_avail(const struct dql *dql)
{
- return dql->adj_limit - dql->num_queued;
+ return ACCESS_ONCE(dql->adj_limit) - ACCESS_ONCE(dql->num_queued);
}
^ permalink raw reply related
* Re: [PATCH net-next 2/3] ipv6: mld: do not overwrite uri when receiving an mldv2 query
From: David L Stevens @ 2014-09-25 23:29 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, hannes, netdev
In-Reply-To: <542475E3.6030508@redhat.com>
On 09/25/2014 04:06 PM, Daniel Borkmann wrote:
> from that query; both specifications also specify different default values for
> URI, where we would have already overwritten a pre-configured URI default value
> for v1 when we previously received a v2 query. While we have tunable for IPv4
> case via commit 2690048c01f32 ("net: igmp: Allow user-space configuration of
> igmp unsolicited report interval") and for IPv6 case via commit fc4eba58b4c1
> ("ipv6: make unsolicited report intervals configurable for mld"), this renders
> any admin provided IPv6 specific configuration useless.
PS -
I didn't address this part -- I don't object at all to resetting the value
when doing a version switch, or even if we lose a querier for a while. That
isn't what your patch does.
+-DLS
^ permalink raw reply
* Re: [PATCH net-next 2/3] ipv6: mld: do not overwrite uri when receiving an mldv2 query
From: David L Stevens @ 2014-09-25 23:23 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, hannes, netdev
In-Reply-To: <542475E3.6030508@redhat.com>
On 09/25/2014 04:06 PM, Daniel Borkmann wrote:
> One of the problems I see (also with this argumentation -- next to the fact
> that it's not specified by the RFC) is that we're blindly overwriting with
You say "not specfied by the RFC" as if it's contrary to the RFC, when the RFC
also doesn't specify that it be set per-host via sysctl. It isn't specified means
that it is up to the implementation how to set it, and the implementation sets it
based on MRD. It does not say "SHOULD" or "MUST" for how this value is set, so
to be clear: the current mechanism is RFC-compliant.
Now you want to change this mechanism that is not covered by RFC to a different
mechanism. Is your change better?
I'm not sure what problem you're trying to fix (which is what I was asking),
but I think a fixed-value specified at each host, rather than one done via the
querier, is in fact worse, especially if that value is much greater or much smaller
than the MRD value, since it is effectively for the same purpose -- just for
unsolicited instead of queried reports.
Now, probably that discussion should've happened when the tunables were put in, but
having the sysctl's is still useful for setting the values when there is no querier
present.
When there is a querier, however, the original code IMO makes more sense, especially
in the absence of any input from an administrator.
I'm generally for allowing administrators complete flexibility, even if they use it
for evil, so I think I'd prefer something along the lines of:
1) have an initial default of 1sec (v2) or 10sec (v1)
2) if an administrator sets the sysctl, override any
other choice with that setting
3) if an administator has not set it, use the querier value
That combination allows the querier to effectively set an appropriate interval for
the entire network, allows an admin to change it per-host if desired, and uses the
suggested defaults when there is no querier or admin intervention.
Or maybe split the sysctls into one that forces the value and one that just sets
a default which can be overridden by queriers.
I don't think your patches are incorrect, but I don't think the original behavior
is either. With your interpretation, the URI (but not the MRD or QRV), must be
changed on every individual host to tune a network away from the default values.
The current code doesn't have that problem.
+-DLS
^ permalink raw reply
* Re: [Patch net-next] net_sched: remove the first parameter from tcf_exts_destroy()
From: Jamal Hadi Salim @ 2014-09-25 23:11 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: davem
In-Reply-To: <1411665997-11013-1-git-send-email-xiyou.wangcong@gmail.com>
On 09/25/14 13:26, Cong Wang wrote:
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Jamal Hadi Salim <hadi@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [Patch net-next 1/2] net_sched: fix errno in tcindex_set_parms()
From: John Fastabend @ 2014-09-25 22:57 UTC (permalink / raw)
To: John Fastabend; +Cc: Cong Wang, netdev, davem
In-Reply-To: <5424842A.60802@intel.com>
On 09/25/2014 02:07 PM, John Fastabend wrote:
> On 09/25/2014 12:06 PM, Cong Wang wrote:
>> When kmemdup() fails, we should return -ENOMEM.
>>
>> Cc: John Fastabend <john.fastabend@gmail.com>
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>> ---
>
> Acked-by: John Fastabend <john.r.fastabend@intel.com>
>
> Thanks Cong.
>
Related to this we should probably push error messages
from the dump routines correctly. If you see u32_dump()
returns a -EINVAL even though it was due to a memory
allocation failure. This is not necessarily due to my
patches though I think the error returning from dump
has always been a simple -1 value.
I'll take a look at it, unless you beat me to it, after
I finish up the percpu stats which I'm doing now.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: IPv6 FIB related crash with MACVLANs in 3.9.11+ kernel.
From: Hongmei Li @ 2014-09-25 22:24 UTC (permalink / raw)
To: netdev
In-Reply-To: <20140208172310.GF16198@order.stressinduktion.org>
Hi Hannes and Ben,
I encounter the same kernel panic.
Do you guys have any progress on this issue?
Thanks and Best Regards,
Hongmei
^ permalink raw reply
* [PATCH net-next] net: reorganize sk_buff for faster __copy_skb_header()
From: Eric Dumazet @ 2014-09-25 21:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Amir Vadai, John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <1411678046.16953.45.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
With proliferation of bit fields in sk_buff, __copy_skb_header() became
quite expensive, showing as the most expensive function in a GSO
workload.
__copy_skb_header() performance is also critical for non GSO TCP
operations, as it is used from skb_clone()
This patch carefully moves all the fields that were not copied in a
separate zone : cloned, nohdr, fclone, peeked, head_frag, xmit_more
Then I moved all other fields and all other copied fields in a section
delimited by headers_start[0]/headers_end[0] section so that we
can use a single memcpy() call, inlined by compiler using long
word load/stores.
I also tried to make all copies in the natural orders of sk_buff,
to help hardware prefetching.
I made sure sk_buff size did not change.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/skbuff.h | 132 ++++++++++++++++++++-------------------
net/core/skbuff.c | 80 ++++++++++++-----------
2 files changed, 112 insertions(+), 100 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f1bfa3781c75..180f55b9ef21 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -527,27 +527,41 @@ struct sk_buff {
char cb[48] __aligned(8);
unsigned long _skb_refdst;
+ void (*destructor)(struct sk_buff *skb);
#ifdef CONFIG_XFRM
struct sec_path *sp;
#endif
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ struct nf_conntrack *nfct;
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ struct nf_bridge_info *nf_bridge;
+#endif
unsigned int len,
data_len;
__u16 mac_len,
hdr_len;
- union {
- __wsum csum;
- struct {
- __u16 csum_start;
- __u16 csum_offset;
- };
- };
- __u32 priority;
+
+ /* Following fields are _not_ copied in __copy_skb_header()
+ * Note that queue_mapping is here mostly to fill a hole.
+ */
kmemcheck_bitfield_begin(flags1);
- __u8 ignore_df:1,
- cloned:1,
- ip_summed:2,
+ __u16 queue_mapping;
+ __u8 cloned:1,
nohdr:1,
- nfctinfo:3;
+ fclone:2,
+ peeked:1,
+ head_frag:1,
+ xmit_more:1;
+ /* one bit hole */
+ kmemcheck_bitfield_end(flags1);
+
+
+
+ /* fields enclosed in headers_start/headers_end are copied
+ * using a single memcpy() in __copy_skb_header()
+ */
+ __u32 headers_start[0];
/* if you move pkt_type around you also must adapt those constants */
#ifdef __BIG_ENDIAN_BITFIELD
@@ -558,58 +572,52 @@ struct sk_buff {
#define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)
__u8 __pkt_type_offset[0];
- __u8 pkt_type:3,
- fclone:2,
- ipvs_property:1,
- peeked:1,
- nf_trace:1;
- kmemcheck_bitfield_end(flags1);
- __be16 protocol;
-
- void (*destructor)(struct sk_buff *skb);
-#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
- struct nf_conntrack *nfct;
-#endif
-#ifdef CONFIG_BRIDGE_NETFILTER
- struct nf_bridge_info *nf_bridge;
-#endif
-
- int skb_iif;
-
- __u32 hash;
-
- __be16 vlan_proto;
- __u16 vlan_tci;
-
-#ifdef CONFIG_NET_SCHED
- __u16 tc_index; /* traffic control index */
-#ifdef CONFIG_NET_CLS_ACT
- __u16 tc_verd; /* traffic control verdict */
-#endif
-#endif
-
- __u16 queue_mapping;
- kmemcheck_bitfield_begin(flags2);
- __u8 xmit_more:1;
-#ifdef CONFIG_IPV6_NDISC_NODETYPE
- __u8 ndisc_nodetype:2;
-#endif
+ __u8 pkt_type:3;
__u8 pfmemalloc:1;
+ __u8 ignore_df:1;
+ __u8 nfctinfo:3;
+
+ __u8 nf_trace:1;
+ __u8 ip_summed:2;
__u8 ooo_okay:1;
__u8 l4_hash:1;
__u8 sw_hash:1;
__u8 wifi_acked_valid:1;
__u8 wifi_acked:1;
+
__u8 no_fcs:1;
- __u8 head_frag:1;
/* Indicates the inner headers are valid in the skbuff. */
__u8 encapsulation:1;
__u8 encap_hdr_csum:1;
__u8 csum_valid:1;
__u8 csum_complete_sw:1;
- /* 1/3 bit hole (depending on ndisc_nodetype presence) */
- kmemcheck_bitfield_end(flags2);
+ __u8 csum_level:2;
+ __u8 csum_bad:1;
+#ifdef CONFIG_IPV6_NDISC_NODETYPE
+ __u8 ndisc_nodetype:2;
+#endif
+ /* 6/8 bit hole */
+
+#ifdef CONFIG_NET_SCHED
+ __u16 tc_index; /* traffic control index */
+#ifdef CONFIG_NET_CLS_ACT
+ __u16 tc_verd; /* traffic control verdict */
+#endif
+#endif
+
+ union {
+ __wsum csum;
+ struct {
+ __u16 csum_start;
+ __u16 csum_offset;
+ };
+ };
+ __u32 priority;
+ int skb_iif;
+ __u32 hash;
+ __be16 vlan_proto;
+ __u16 vlan_tci;
#if defined CONFIG_NET_DMA || defined CONFIG_NET_RX_BUSY_POLL
union {
unsigned int napi_id;
@@ -625,19 +633,18 @@ struct sk_buff {
__u32 reserved_tailroom;
};
- kmemcheck_bitfield_begin(flags3);
- __u8 csum_level:2;
- __u8 csum_bad:1;
- /* 13 bit hole */
- kmemcheck_bitfield_end(flags3);
-
__be16 inner_protocol;
__u16 inner_transport_header;
__u16 inner_network_header;
__u16 inner_mac_header;
+
+ __be16 protocol;
__u16 transport_header;
__u16 network_header;
__u16 mac_header;
+
+ __u32 headers_end[0];
+
/* These elements must be at the end, see alloc_skb() for details. */
sk_buff_data_t tail;
sk_buff_data_t end;
@@ -3025,19 +3032,22 @@ static inline void nf_reset_trace(struct sk_buff *skb)
}
/* Note: This doesn't put any conntrack and bridge info in dst. */
-static inline void __nf_copy(struct sk_buff *dst, const struct sk_buff *src)
+static inline void __nf_copy(struct sk_buff *dst, const struct sk_buff *src,
+ bool copy)
{
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
dst->nfct = src->nfct;
nf_conntrack_get(src->nfct);
- dst->nfctinfo = src->nfctinfo;
+ if (copy)
+ dst->nfctinfo = src->nfctinfo;
#endif
#ifdef CONFIG_BRIDGE_NETFILTER
dst->nf_bridge = src->nf_bridge;
nf_bridge_get(src->nf_bridge);
#endif
#if IS_ENABLED(CONFIG_NETFILTER_XT_TARGET_TRACE) || defined(CONFIG_NF_TABLES)
- dst->nf_trace = src->nf_trace;
+ if (copy)
+ dst->nf_trace = src->nf_trace;
#endif
}
@@ -3049,7 +3059,7 @@ static inline void nf_copy(struct sk_buff *dst, const struct sk_buff *src)
#ifdef CONFIG_BRIDGE_NETFILTER
nf_bridge_put(dst->nf_bridge);
#endif
- __nf_copy(dst, src);
+ __nf_copy(dst, src, true);
}
#ifdef CONFIG_NETWORK_SECMARK
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 06a8feb10099..57821927700e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -261,7 +261,6 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
atomic_t *fclone_ref = (atomic_t *) (child + 1);
kmemcheck_annotate_bitfield(child, flags1);
- kmemcheck_annotate_bitfield(child, flags2);
skb->fclone = SKB_FCLONE_ORIG;
atomic_set(fclone_ref, 1);
@@ -674,57 +673,61 @@ void consume_skb(struct sk_buff *skb)
}
EXPORT_SYMBOL(consume_skb);
+/* Make sure a field is enclosed inside headers_start/headers_end section */
+#define CHECK_SKB_FIELD(field) \
+ BUILD_BUG_ON(offsetof(struct sk_buff, field) < \
+ offsetof(struct sk_buff, headers_start)); \
+ BUILD_BUG_ON(offsetof(struct sk_buff, field) >= \
+ offsetof(struct sk_buff, headers_end)); \
+
static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
{
new->tstamp = old->tstamp;
+ /* We do not copy old->sk */
new->dev = old->dev;
- new->transport_header = old->transport_header;
- new->network_header = old->network_header;
- new->mac_header = old->mac_header;
- new->inner_protocol = old->inner_protocol;
- new->inner_transport_header = old->inner_transport_header;
- new->inner_network_header = old->inner_network_header;
- new->inner_mac_header = old->inner_mac_header;
+ memcpy(new->cb, old->cb, sizeof(old->cb));
skb_dst_copy(new, old);
- skb_copy_hash(new, old);
- new->ooo_okay = old->ooo_okay;
- new->no_fcs = old->no_fcs;
- new->encapsulation = old->encapsulation;
- new->encap_hdr_csum = old->encap_hdr_csum;
- new->csum_valid = old->csum_valid;
- new->csum_complete_sw = old->csum_complete_sw;
#ifdef CONFIG_XFRM
new->sp = secpath_get(old->sp);
#endif
- memcpy(new->cb, old->cb, sizeof(old->cb));
- new->csum = old->csum;
- new->ignore_df = old->ignore_df;
- new->pkt_type = old->pkt_type;
- new->ip_summed = old->ip_summed;
- skb_copy_queue_mapping(new, old);
- new->priority = old->priority;
-#if IS_ENABLED(CONFIG_IP_VS)
- new->ipvs_property = old->ipvs_property;
+ __nf_copy(new, old, false);
+
+ /* Note : this field could be in headers_start/headers_end section
+ * It is not yet because we do not want to have a 16 bit hole
+ */
+ new->queue_mapping = old->queue_mapping;
+
+ memcpy(&new->headers_start, &old->headers_start,
+ offsetof(struct sk_buff, headers_end) -
+ offsetof(struct sk_buff, headers_start));
+ CHECK_SKB_FIELD(protocol);
+ CHECK_SKB_FIELD(csum);
+ CHECK_SKB_FIELD(hash);
+ CHECK_SKB_FIELD(priority);
+ CHECK_SKB_FIELD(skb_iif);
+ CHECK_SKB_FIELD(vlan_proto);
+ CHECK_SKB_FIELD(vlan_tci);
+ CHECK_SKB_FIELD(transport_header);
+ CHECK_SKB_FIELD(network_header);
+ CHECK_SKB_FIELD(mac_header);
+ CHECK_SKB_FIELD(inner_protocol);
+ CHECK_SKB_FIELD(inner_transport_header);
+ CHECK_SKB_FIELD(inner_network_header);
+ CHECK_SKB_FIELD(inner_mac_header);
+ CHECK_SKB_FIELD(mark);
+#ifdef CONFIG_NETWORK_SECMARK
+ CHECK_SKB_FIELD(secmark);
+#endif
+#ifdef CONFIG_NET_RX_BUSY_POLL
+ CHECK_SKB_FIELD(napi_id);
#endif
- new->pfmemalloc = old->pfmemalloc;
- new->protocol = old->protocol;
- new->mark = old->mark;
- new->skb_iif = old->skb_iif;
- __nf_copy(new, old);
#ifdef CONFIG_NET_SCHED
- new->tc_index = old->tc_index;
+ CHECK_SKB_FIELD(tc_index);
#ifdef CONFIG_NET_CLS_ACT
- new->tc_verd = old->tc_verd;
+ CHECK_SKB_FIELD(tc_verd);
#endif
#endif
- new->vlan_proto = old->vlan_proto;
- new->vlan_tci = old->vlan_tci;
-
- skb_copy_secmark(new, old);
-#ifdef CONFIG_NET_RX_BUSY_POLL
- new->napi_id = old->napi_id;
-#endif
}
/*
@@ -875,7 +878,6 @@ struct sk_buff *skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
return NULL;
kmemcheck_annotate_bitfield(n, flags1);
- kmemcheck_annotate_bitfield(n, flags2);
n->fclone = SKB_FCLONE_UNAVAILABLE;
}
^ permalink raw reply related
* Re: [Patch net-next 2/2] net_sched: fix another regression in cls_tcindex
From: John Fastabend @ 2014-09-25 21:18 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: davem, John Fastabend
In-Reply-To: <1411671965-18887-2-git-send-email-xiyou.wangcong@gmail.com>
On 09/25/2014 12:06 PM, Cong Wang wrote:
> Clearly the following change is not expected:
>
> - if (!cp.perfect && !cp.h)
> - cp.alloc_hash = cp.hash;
> + if (!cp->perfect && cp->h)
> + cp->alloc_hash = cp->hash;
>
> Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/sched/cls_tcindex.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
> index 9d78fd7..a18eb1b 100644
> --- a/net/sched/cls_tcindex.c
> +++ b/net/sched/cls_tcindex.c
> @@ -303,7 +303,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
> cp->hash = DEFAULT_HASH_SIZE;
> }
>
> - if (!cp->perfect && cp->h)
> + if (!cp->perfect && !cp->h)
> cp->alloc_hash = cp->hash;
>
> /* Note: this could be as restrictive as if (handle & ~(mask >> shift))
>
Dang thanks. I added a test to my scripts that doesn't set the
hash explicitly with TCA_TCINDEX_HASH. It looks like changes to
the filter after the initial setup could fail without this fix.
Acked-by: John Fastabend <john.r.fastabend@intel.com>
^ permalink raw reply
* Re: [PATCH net] ematch: Fix matching of inverted containers.
From: Cong Wang @ 2014-09-25 21:08 UTC (permalink / raw)
To: Ignacy Gawędzki, netdev; +Cc: Thomas Graf
In-Reply-To: <20140924163839.GA6925@zenon.in.qult.net>
(Cc'ing Thomas)
On Wed, Sep 24, 2014 at 9:38 AM, Ignacy Gawędzki
<ignacy.gawedzki@green-communications.fr> wrote:
> Negated expressions and sub-expressions need to have their flags checked for
> TCF_EM_INVERT and their result negated accordingly.
>
> Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
> ---
> net/sched/ematch.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/sched/ematch.c b/net/sched/ematch.c
> index 3a633de..ad57f44 100644
> --- a/net/sched/ematch.c
> +++ b/net/sched/ematch.c
> @@ -526,9 +526,11 @@ pop_stack:
> match_idx = stack[--stackp];
> cur_match = tcf_em_get_match(tree, match_idx);
>
> - if (tcf_em_early_end(cur_match, res))
> + if (tcf_em_early_end(cur_match, res)) {
> + if (tcf_em_is_inverted(cur_match))
> + res = !res;
> goto pop_stack;
> - else {
> + } else {
> match_idx++;
> goto proceed;
> }
> --
> 1.9.1
> --
> 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 net-next 1/2] net_sched: fix errno in tcindex_set_parms()
From: John Fastabend @ 2014-09-25 21:07 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: davem, John Fastabend
In-Reply-To: <1411671965-18887-1-git-send-email-xiyou.wangcong@gmail.com>
On 09/25/2014 12:06 PM, Cong Wang wrote:
> When kmemdup() fails, we should return -ENOMEM.
>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Thanks Cong.
> net/sched/cls_tcindex.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
> index 5054fae..9d78fd7 100644
> --- a/net/sched/cls_tcindex.c
> +++ b/net/sched/cls_tcindex.c
> @@ -237,15 +237,14 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
> if (err < 0)
> return err;
>
> + err = -ENOMEM;
> /* tcindex_data attributes must look atomic to classifier/lookup so
> * allocate new tcindex data and RCU assign it onto root. Keeping
> * perfect hash and hash pointers from old data.
> */
> cp = kzalloc(sizeof(*cp), GFP_KERNEL);
> - if (!cp) {
> - err = -ENOMEM;
> + if (!cp)
> goto errout;
> - }
>
> cp->mask = p->mask;
> cp->shift = p->shift;
>
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Joe Perches @ 2014-09-25 20:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, David Miller, netdev, Amir Vadai,
John Fastabend
In-Reply-To: <1411678046.16953.45.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-09-25 at 13:47 -0700, Eric Dumazet wrote:
> After patch :
> 32.78% [kernel] [k] __copy_skb_header
> After __copy_skb_header() optimization I get something even nicer ;)
> 19.90% [kernel] [k] __copy_skb_header
> I'll post this patch asap.
Eric, you are _killing_ it. network ninja indeed...
^ permalink raw reply
* Re: [PATCH v3 net-next 1/3] ipv4: rename ip_options_echo to __ip_options_echo()
From: Joe Perches @ 2014-09-25 20:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, David S. Miller, netdev, Yuchung Cheng,
Neal Cardwell, Christoph Paasch, Julia Lawall
In-Reply-To: <1411677484.16953.43.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-09-25 at 13:38 -0700, Eric Dumazet wrote:
> On Thu, 2014-09-25 at 13:30 -0700, Joe Perches wrote:
>
> > Unrelated:
> >
> > I wonder how much effort, if any, should be made to convert
> > struct sk_buff * to const struct sk_buff * where appropriate.
> >
> > For instance:
> >
> > This __ip_options_echo could use const struct sk_buff *skb
> > if fib_compute_spec_dst was changed to const struct sk_buff *skb.
>
> Well, this seems something certainly doable, as a follow up ;)
It's doable, but it seems a non-trivial inspection task.
I believe coccinelle does not have the ability to automate this.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: exploit skb->xmit_more to conditionally send doorbell
From: Eric Dumazet @ 2014-09-25 20:47 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: David Miller, netdev, Amir Vadai, John Fastabend
In-Reply-To: <1411659380.16953.29.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-09-25 at 08:36 -0700, Eric Dumazet wrote:
> After patch :
>
> 32.78% [kernel] [k] __copy_skb_header
> 8.26% [kernel] [k] mlx4_en_xmit
> 7.25% [kernel] [k] __alloc_skb
> 7.18% [kernel] [k] copy_user_enhanced_fast_string
> 4.39% [kernel] [k] skb_segment
> 2.87% [kernel] [k] memcpy
> 2.59% [kernel] [k] tcp_sendmsg
> 2.50% [kernel] [k] _raw_spin_lock
> 2.38% [kernel] [k] dev_hard_start_xmit
> 1.52% [kernel] [k] tcp_gso_segment
> 1.50% [kernel] [k] kmem_cache_alloc_node_trace
> 1.40% [kernel] [k] kmem_cache_alloc_node
> 1.16% [kernel] [k] ip_send_check
>
After __copy_skb_header() optimization I get something even nicer ;)
19.90% [kernel] [k] __copy_skb_header
15.16% [kernel] [k] skb_segment
7.02% [kernel] [k] __alloc_skb
6.89% [kernel] [k] copy_user_enhanced_fast_string
6.60% [kernel] [k] mlx4_en_xmit
2.70% [kernel] [k] _raw_spin_lock
2.68% [kernel] [k] memcpy
2.41% [kernel] [k] tcp_sendmsg
I'll post this patch asap.
^ permalink raw reply
* Re: [PATCH v3 net-next 1/3] ipv4: rename ip_options_echo to __ip_options_echo()
From: Eric Dumazet @ 2014-09-25 20:38 UTC (permalink / raw)
To: Joe Perches
Cc: Eric Dumazet, David S. Miller, netdev, Yuchung Cheng,
Neal Cardwell, Christoph Paasch
In-Reply-To: <1411677008.3460.7.camel@joe-AO725>
On Thu, 2014-09-25 at 13:30 -0700, Joe Perches wrote:
> Unrelated:
>
> I wonder how much effort, if any, should be made to convert
> struct sk_buff * to const struct sk_buff * where appropriate.
>
> For instance:
>
> This __ip_options_echo could use const struct sk_buff *skb
> if fib_compute_spec_dst was changed to const struct sk_buff *skb.
Well, this seems something certainly doable, as a follow up ;)
^ 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