etlink_seq_stop().
> --
Yes, two places use rht_dereference() instead of rht_dereference_rcu()
[PATCH net-next] netlink: fix lockdep splats
With netlink_lookup() conversion to RCU, we need to use appropriate
rcu dereference in netlink_seq_socket_idx() & netlink_seq_next()
Reported-by: Sasha L
On Fri, 2016-04-22 at 17:31 +0200, Nicolas Dichtel wrote:
> nla_data() is now aligned on a 64-bit area.
>
> Signed-off-by: Nicolas Dichtel
> ---
> include/net/netlink.h | 8 +---
> include/net/nl802154.h| 6 ++
> net/ieee802154/nl802154.c | 13 -
> 3 files changed,
On Fri, 2016-08-19 at 16:47 -0300, Thadeu Lima de Souza Cascardo wrote:
> Instead of using flow stats per NUMA node, use it per CPU. When using
> megaflows, the stats lock can be a bottleneck in scalability.
...
>
> flow_cache = kmem_cache_create("sw_flow", sizeof(struct sw_flow)
> -
On Fri, 2016-08-19 at 18:09 -0700, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 19 Aug 2016 12:56:56 -0700
>
> > On Fri, 2016-08-19 at 16:47 -0300, Thadeu Lima de Souza Cascardo wrote:
> >> Instead of using flow stats per NUMA node, use it per CPU. When using
&
On Thu, 2016-09-15 at 19:11 -0300, Thadeu Lima de Souza Cascardo wrote:
> Instead of using flow stats per NUMA node, use it per CPU. When using
> megaflows, the stats lock can be a bottleneck in scalability.
>
> On a E5-2690 12-core system, usual throughput went from ~4Mpps to
> ~15Mpps when forwa
On Fri, 2015-07-10 at 16:19 +0200, Thomas Graf wrote:
> From: Roopa Prabhu
> + if (oif)
> + dev = __dev_get_by_index(net, oif);
> + ret = lwtunnel_build_state(dev, encap_type,
> +encap, &lwtstate);
> + if (!ret) {
> + lwtunnel_s
Hi Simon
On Tue, 2014-06-03 at 11:38 +0900, Simon Horman wrote:
> +/* If MPLS offload request, verify we are testing hardware MPLS features
> + * instead of standard features for the netdev.
> + */
> +#ifdef CONFIG_NET_MPLS_GSO
> +static netdev_features_t net_mpls_features(struct sk_buff *skb,
> +
On Fri, 2016-01-15 at 15:33 +0100, Hannes Frederic Sowa wrote:
> It was seen that defective configurations of openvswitch could overwrite
> the STACK_END_MAGIC and cause a hard crash of the kernel because of too
> many recursions within ovs.
...
> +
> + preempt_disable();
> + level = __th
On Mon, 2013-01-07 at 18:31 -0800, Pravin B Shelar wrote:
> From: Pravin Shelar
Do you have some perf numbers to share ?
> Signed-off-by: Pravin B Shelar
> ---
> include/linux/skbuff.h | 12 ++
> include/net/gre.h |6 +++
> net/ipv4/af_inet.c |1 +
> net/ipv4/gre.c
ct netdevice by one pointer and reduces number of needed
> rcu_dereference calls from 2 to 1.
>
Thats not true.
> Note this also fixes the race bug pointed out by Steven Rostedt and
> fixed by patch "[PATCH] net: add a synchronize_net() in
> netdev_rx_handler_unregister()
On Sat, 2013-03-30 at 18:13 +0100, Jiri Pirko wrote:
> Well, not entirely true, depends on arch.
>
Are you really trying to obfuscate stack because of Alpha architecture ?
Really, a bit of stability in this code is welcome.
Lets fix existing bugs instead of possibly add new ones.
__
On Sat, 2013-03-30 at 12:28 -0700, Eric Dumazet wrote:
> On Sat, 2013-03-30 at 18:13 +0100, Jiri Pirko wrote:
>
> > Well, not entirely true, depends on arch.
> >
>
> Are you really trying to obfuscate stack because of Alpha architecture ?
By the way, only dev->
On Sat, 2013-03-30 at 12:31 -0700, Eric Dumazet wrote:
> By the way, only dev->rx_handler needs to be RCU protected.
>
> The patch send yesterday make the second rcu_dereference() (to get
> rx_handler_data) totally irrelevant.
I'll send patch when yesterday fix is
On Fri, 2013-04-26 at 17:46 -0400, Peter Klausler wrote:
> Tune flow table lookup in net/openvswitch, replacing a call to
> the slow-but-safe memcmp() in lib/string.c with a key comparator
> routine that presumes most comparisons will succeed. Besides
> avoiding an early-exit test on each iteratio
On Fri, 2013-05-17 at 15:49 +0900, Simon Horman wrote:
> In the case where the ability to offload checksums changes
> then it may be necessary for software checksumming of an skb to occur.
>
> An example of such a case is where a non-GRE packet is received but
> is to be encapsulated and transmitt
On Fri, 2013-05-17 at 15:50 +0900, Simon Horman wrote:
> @@ -509,6 +511,8 @@ struct sk_buff {
> __u32 reserved_tailroom;
> };
>
> + __be16 inner_protocol;
> + /* 16/48 bit hole */
> sk_buff_data_t inner_transport_header;
>
64K MTU.
Verify if the acking and collapsing resulted in a headroom exceeding
what csum_start can cover and reallocate the headroom if so.
A big thank you to Jim Foraker and the team at
LLNL for helping out with the investiga
On Fri, 2013-05-24 at 16:52 +0200, Thomas Graf wrote:
> Make the skb zerocopy logic written for nfnetlink queue available for
> use by other modules.
>
> Signed-off-by: Thomas Graf
> ---
> include/linux/skbuff.h | 2 ++
> net/core/skbuff.c| 46 +
On Fri, 2013-05-24 at 10:24 -0700, Jesse Gross wrote:
> Does this have any impact on small packets? Those are usually the
> common case (i.e. TCP SYN) and I think this is slightly less optimal
> for those.
No difference at all, small packets are copied anyway in skb->head
_
On Fri, 2013-05-24 at 14:23 -0700, Jesse Gross wrote:
> On Fri, May 24, 2013 at 11:58 AM, Eric Dumazet wrote:
> > On Fri, 2013-05-24 at 10:24 -0700, Jesse Gross wrote:
> >
> >> Does this have any impact on small packets? Those are usually the
> >> common case (
On Fri, 2013-05-24 at 15:18 -0700, Jesse Gross wrote:
> Offloads are supported. What I want to know is how they affect
> performance with this change.
Hmm, I do not understand why you are checksumming then.
skb_copy_and_csum_dev() is a killer.
___
d
On Fri, 2013-05-24 at 17:08 -0700, Jesse Gross wrote:
> What's the alternative?
I guess Thomas was working on this ;)
We addressed all this on nfnetlink lately.
Presumably GSO stuff is a non issue for vSwitch upcalls.
But UDP messages can be big, and their checksum might be already
validated b
On Sat, 2013-05-25 at 08:02 +0100, Thomas Graf wrote:
> I ran TCP_CRR to verify the SYN/ACK use case and I did not
> observe a difference. If you have any specific test in mind
> I will be glad to run that before posting the 2nd revision.
I guess you should test with rx checksum disabled as well,
On Wed, 2013-06-12 at 19:05 +1000, Dave Wiltshire wrote:
> Some call sites to pskb_expand_head subsequently update the skb truesize
> and others don't (even with non-zero arguments). This is likely a memory
> audit leak. Fixed this up by moving the memory accounting to the
> skbuff.c file and remov
On Wed, 2013-06-26 at 16:34 +0900, Isaku Yamahata wrote:
> Reset pkt_type to PACKET_HOST when loopback device receives packet
> before calling eth_type_trans()
>
> ip-encapsulated packets can be handled by localhost. But skb->pkt_type
> can be PACKET_OTHERHOST when packet comes into ip tunnel devi
On Thu, 2012-10-18 at 20:55 -0700, Joe Perches wrote:
> ethernet, ipv4, and ipv6 address testing uses 3 different api naming styles.
>
> ethernet uses:is__ether_addr
> ipv4 uses:ipv4_is_
> ipv6 uses:ipv6_addr_
>
> Standardize on the ipv6 style of _addr_ to reduce
> the number of s
On Thu, 2012-04-12 at 16:42 +0900, Simon Horman wrote:
> This hook is based on a hook of the same name provided by UDP. It provides
> a way for to receive packets that have a TCP header and treat them in some
> alternate way.
>
> It is intended to be used by an implementation of the STT tunneling
path does a single JMP .
When static_key is enabled, JMP destination is patched to reach the real
encap_type/encap_rcv logic, possibly adding cache misses.
Signed-off-by: Eric Dumazet
Cc: Simon Horman
Cc: dev@openvswitch.org
---
include/net/udp.h|1 +
net/ipv4/udp.c | 12
On Thu, 2012-04-12 at 11:05 +0200, Eric Dumazet wrote:
> If static_key is not yet enabled, the fast path does a single JMP .
>
> When static_key is enabled, JMP destination is patched to reach the real
> encap_type/encap_rcv logic, possibly adding cache misses.
Small note Simon,
Th
Le mercredi 23 novembre 2011 à 15:54 +0800, Herbert Xu a écrit :
> David Miller wrote:
> >
> > I would like to see some discussion wrt. Jamal's feedback, which is that
> > a lot of the side-band functionality added by this code is either 1) already
> > doable with packet scheduler actions or 2) s
Le mercredi 23 novembre 2011 à 07:47 -0500, jamal a écrit :
> On Wed, 2011-11-23 at 09:12 +0100, Eric Dumazet wrote:
>
> > I had no time to look at OVS, but current tc model is not scalable,
> > everything is performed under a queue lock.
> > Maybe its time to redesi
Le mercredi 23 novembre 2011 à 08:36 -0500, jamal a écrit :
> If you wanna do this right - I suggest you get a different domain name.
> tc.org or something along those lines.
> Start aggregating documentation that is validated to be working. There's
> a lot of "opinions" out there instead of facts
Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
> The problem is that there are two flow classifiers, one in OpenVswitch
> in the kernel, and the other in the user space flow manager. I think the
> issue is that the two have different code.
We have kind of same duplication in
Le vendredi 25 novembre 2011 à 01:25 -0500, David Miller a écrit :
> From: Eric Dumazet
> Date: Fri, 25 Nov 2011 07:18:03 +0100
>
> > Le jeudi 24 novembre 2011 à 21:20 -0800, Stephen Hemminger a écrit :
> >
> >> The problem is that there are two flow classifiers,
Le vendredi 25 novembre 2011 à 06:34 -0500, jamal a écrit :
> Hrm. I forgot about the flow classifier - it may be what the openflow
> folks need. It is more friendly for the well defined tuples than u32.
>
> But what do you mean "refactor"? I can already use this classifier
> and attach actions to
Le vendredi 25 novembre 2011 à 14:02 +0100, Eric Dumazet a écrit :
> cls_flow is not complete, since it doesnt handle tunnels for example.
>
> It calls a 'partial flow classifier' to find each needed element, one by
> one.
> (adding tunnel decap would need to perform t
all.
Signed-off-by: Eric Dumazet
---
include/net/flow_keys.h | 15
net/core/Makefile |2
net/core/flow_dissector.c | 134
3 files changed, 150 insertions(+), 1 deletion(-)
diff --git a/include/net/flow_keys.h b/include/net/flow_keys.h
No functional changes.
This uses the code we factorized in skb_flow_dissect()
Signed-off-by: Eric Dumazet
---
net/core/dev.c | 125 +--
1 file changed, 14 insertions(+), 111 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8afb244
Instead of using a custom flow dissector, use skb_flow_dissect() and
benefit from tunnelling support.
This lack of tunnelling support was mentioned by Dan Siemon.
Signed-off-by: Eric Dumazet
---
net/sched/cls_flow.c | 180 ++---
1 file changed, 48
Current SFB double hashing is not fulfilling SFB theory, if two flows
share same rxhash value.
Using skb_flow_dissect() permits to really have better hash dispersion,
and get tunnelling support as well.
Double hashing point was mentioned by Florian Westphal
Signed-off-by: Eric Dumazet
---
net
Le mercredi 30 novembre 2011 à 08:14 -0500, jamal a écrit :
> On Wed, 2011-11-30 at 15:00 +0800, Herbert Xu wrote:
>
>
> > The other factor I considered is scalability. The OVS code as is
> > is not really friendly to SMP/NUMA scalability (but as Eric pointed,
> > neither is the classifier/actio
41 matches
Mail list logo
