* Re: [PATCH] neigh: remove duplicated log msg
From: David Miller @ 2016-04-06 18:20 UTC (permalink / raw)
To: abdelmajidx.mlayeh
Cc: linux-kernel, dsa, edumazet, martinbj2008, koct9i, ja,
rick.jones2, netdev
In-Reply-To: <1459946535-6015-1-git-send-email-abdelmajidx.mlayeh@intel.com>
From: Abdelmajid Mlayeh <abdelmajidx.mlayeh@intel.com>
Date: Wed, 6 Apr 2016 14:42:06 +0200
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
We will not read any patches with attachments like this, sorry.
^ permalink raw reply
* Re: [PATCHv2 net-next] cxgb4/cxgb4vf: Deprecate module parameter dflt_msg_enable
From: David Miller @ 2016-04-06 18:21 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan
In-Reply-To: <1459830141-27224-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 5 Apr 2016 09:52:21 +0530
> Message level can be set through ethtool, so deprecate module parameter
> which is used to set the same.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: David Miller @ 2016-04-06 18:23 UTC (permalink / raw)
To: paul
Cc: pabeni, linux-security-module, james.l.morris, agruenba, sds, fw,
netdev, selinux
In-Reply-To: <CAHC9VhQS+LfPbj0UuKFiVCW7LKthJmgOt08MvCiwKjTZZYstxA@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Wed, 6 Apr 2016 10:07:27 -0400
> "While marking the LSM hook structure doesn't directly affect the
> SELinux netfilter hooks, once we remove the ability to deregister the
> LSM hooks we will have no need to support deregistering netfilter
> hooks and I expect we will drop that functionality as well to help
> decrease the risk of tampering."
This is not a reasonable postiion.
The performance implications are non-trivial for using netfilter hooks
when they aren't actually needed.
^ permalink raw reply
* Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: Paul Moore @ 2016-04-06 18:36 UTC (permalink / raw)
To: David Miller
Cc: pabeni, linux-security-module, James Morris, agruenba,
Stephen Smalley, fw, netdev, selinux
In-Reply-To: <20160406.142316.1728426867290841888.davem@davemloft.net>
On Wed, Apr 6, 2016 at 2:23 PM, David Miller <davem@davemloft.net> wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Wed, 6 Apr 2016 10:07:27 -0400
>
>> "While marking the LSM hook structure doesn't directly affect the
>> SELinux netfilter hooks, once we remove the ability to deregister the
>> LSM hooks we will have no need to support deregistering netfilter
>> hooks and I expect we will drop that functionality as well to help
>> decrease the risk of tampering."
>
> This is not a reasonable postiion.
>
> The performance implications are non-trivial for using netfilter hooks
> when they aren't actually needed.
With all due respect, I think you've taken what I consider to be some
unreasonable positions when it comes to the network stack and LSMs in
the past. We have different perspectives and different priorities as
a result, from my perspective the security advantage gained by
eliminating the ability to disable SELinux at runtime is more
important.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: rtlwifi: btcoexist: Convert BTC_PRINTK to btc_<foo>_dbg
From: Kalle Valo @ 2016-04-06 18:39 UTC (permalink / raw)
To: Joe Perches
Cc: linux-kernel, Larry Finger, Chaoming Li, linux-wireless, netdev
In-Reply-To: <4672f9efb37df545ae504d51ca626bf34237fa63.1458258337.git.joe@perches.com>
> Use a more common logging style.
>
> Miscellanea:
>
> o Add specific logging macros for ALGORITHM and INTERFACE types
> o Output the messages at KERN_DEBUG
> o Coalesce formats
> o Align arguments
> o Whitespace style adjustments for only these changes
>
> Signed-off-by: Joe Perches <joe@perches.com>
Thanks, applied to wireless-drivers-next.git. There were some conflicts but
3-way merge was able to fix them. Please double check still.
Applying: rtlwifi: btcoexist: Convert BTC_PRINTK to btc_<foo>_dbg
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
Auto-merging drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
Auto-merging drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
Kalle Valo
^ permalink raw reply
* Re: wl12xx: remove redundant null check on wl->scan.ssid
From: Kalle Valo @ 2016-04-06 18:40 UTC (permalink / raw)
To: Colin Ian King
Cc: Arik Nemtsov, Luca Coelho, Avraham Stern, Eliad Peller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1458318048-28184-1-git-send-email-colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
>
> ssid is an array of u8, so it can never be null, so the null check on
> wl->scan.ssid is redundant and can be removed.
>
> Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
--
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: brcmfmac: sdio: remove unused variable retry_limit
From: Kalle Valo @ 2016-04-06 18:43 UTC (permalink / raw)
To: Colin Ian King
Cc: Brett Rudley, Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Vineet Gupta, Kosuke Tatsukawa,
linux-wireless, brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <1458495292-17701-1-git-send-email-colin.king@canonical.com>
> From: Colin Ian King <colin.king@canonical.com>
>
> retry_limit has never been used during the life of this driver, so
> we may as well remove it as it is redundant.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
^ permalink raw reply
* Re: [v2] mwifiex: advertise low priority scan feature
From: Kalle Valo @ 2016-04-06 18:43 UTC (permalink / raw)
To: Wei-Ning Huang
Cc: Linux Wireless, LKML, akarwar, djkurtz, Wei-Ning Huang, nishants,
netdev
In-Reply-To: <1458619796-7694-1-git-send-email-wnhuang@chromium.org>
> From: Amitkumar Karwar <akarwar@marvell.com>
>
> Low priority scan handling code which delays or aborts scan
> operation based on Tx traffic is removed recently. The reason
> is firmware already takes care of it in our new feature scan
> channel gap. Hence we should advertise low priority scan
> support to cfg80211.
>
> This patch fixes a problem in which OBSS scan request from
> wpa_supplicant was being rejected by cfg80211.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
^ permalink raw reply
* Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update
From: Martin KaFai Lau @ 2016-04-06 18:49 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Eric Dumazet, Wei Wang, Kernel Team
In-Reply-To: <CAM_iQpUrcXwBH0BuCh-cjo0st6ykpUgdjRo3Cn-ViO40vtbHKA@mail.gmail.com>
On Wed, Apr 06, 2016 at 10:58:23AM -0700, Cong Wang wrote:
> On Tue, Apr 5, 2016 at 5:11 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> > On Mon, Apr 04, 2016 at 01:45:02PM -0700, Cong Wang wrote:
> >> I see your point, but calling __ip6_datagram_connect() seems overkill
> >> here, we don't need to update so many things in the pmtu update context,
> >> at least IPv4 doesn't do that either. I don't think you have to do that.
> >>
> >> So why just updating the dst cache (also some addr cache) here is not
> >> enough?
> > I am not sure I understand. I could be missing something.
> >
> > This patch uses ip6_datagram_dst_update() to do the route lookup and
> > sk->sk_dst_cache update. ip6_datagram_dst_update() is
> > created in the first two refactoring patches and is also used by
> > __ip6_datagram_connect().
> >
> > Which operations in ip6_datagram_dst_update() could be saved
> > during the pmtu update?
>
> I thought you call the same ip6_datagram_dst_update() for both
> pmtu update and __ip6_datagram_connect(), but you actually skip
> some sk operations for pmtu case, which means you don't need
> to worry about parallel ip6_datagram_connect().
>
> IPv6 UDP sendmsg() path stores the dst without sock lock anyway,
> we don't cope with a concurrent connect() on another cpu.
A parallel sendmsg and connect could be an issue. The user is connecting
to a new dest while another parallel sendmsg is sending to (could be the old
dest, new dest or somewhere between old and new dest?)
However, it is the userland making and it will be another patch if we want
to protect this case too.
In pmtu update, the kernel is doing the lookup and update without the
userland conscious.
> But still, I don't see this is a problem here, because even if we store
> an obsolete address in cache, it would be corrected later.
The sendmsg() path will correct it (relookup and update sk_dst_cache) but not
the getsockopt(IPV6_MTU) path which is what this patch is trying to fix: Update
a _valid_ dst to sk->sk_dst_cache.
^ permalink raw reply
* Re: [PATCH net] cxgb4: Add pci device id for chelsio t520-cr adapter
From: David Miller @ 2016-04-06 19:07 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan
In-Reply-To: <1459743893-577-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 4 Apr 2016 09:54:53 +0530
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Kalle Valo @ 2016-04-06 19:07 UTC (permalink / raw)
To: Machani, Yaniv
Cc: Pali Rohár, Luciano Coelho, Balbi, Felipe, Chalmers, Kevin,
Shahar Levi, Davis, Andrew, Mishol, Guy, Arik Nemtsov, Gery Kahn,
Felipe Balbi, Luciano Coelho, David Woodhouse, Pavel Machek,
Aaro Koskinen, Ben Hutchings, David Gnedt, Ivaylo Dimitrov,
Sebastian Reichel, Tony Lindgren, Menon, Nishanth,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AE1C82FB3D0EC64DB1F752C81CBD1101390F685E-1tpBd5JUCm6IQmiDNMet8wC/G2K4zDHf@public.gmane.org>
"Machani, Yaniv" <yanivma-l0cyMroinI0@public.gmane.org> writes:
> More than that, wl1251 family is not officially supported via the
> mainline Linux.
I guess you mean not officially supported by TI? Because wl1251 driver
has been in mainline for ages and reportedly working.
--
Kalle Valo
--
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: [PATCH net-next 1/3] net: bcmgenet: cleanup for bcmgenet_xmit()
From: Petri Gynther @ 2016-04-06 19:09 UTC (permalink / raw)
To: David Laight
Cc: netdev@vger.kernel.org, davem@davemloft.net, f.fainelli@gmail.com,
jaedon.shin@gmail.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D54DC5E88@AcuExch.aculab.com>
On Wed, Apr 6, 2016 at 1:57 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Petri Gynther
>> Sent: 05 April 2016 01:10
> ...
>> 2. Readability: Add parentheses around nr_frags + 1.
> ...
>> - if (ring->free_bds <= nr_frags + 1) {
> ...
>> + if (ring->free_bds <= (nr_frags + 1)) {
>
> The extra () are not needed and do not improve readability.
>
> David
>
Not needed from C language point of view, but I personally like it
better that way.
Also, making it consistent with these:
bcmgenet.c:1227: if (ring->free_bds > (MAX_SKB_FRAGS + 1)) {
bcmgenet.c:1523: if (ring->free_bds <= (MAX_SKB_FRAGS + 1))
^ permalink raw reply
* RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Machani, Yaniv @ 2016-04-06 19:12 UTC (permalink / raw)
To: Kalle Valo
Cc: Pali Rohár, Luciano Coelho, Balbi, Felipe, Chalmers, Kevin,
Shahar Levi, Davis, Andrew, Mishol, Guy, Arik Nemtsov, Gery Kahn,
Felipe Balbi, Luciano Coelho, David Woodhouse, Pavel Machek,
Aaro Koskinen, Ben Hutchings, David Gnedt, Ivaylo Dimitrov,
Sebastian Reichel, Tony Lindgren, Menon, Nishanth,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <87lh4q4kuc.fsf-5ukZ45wKbUHoml4zekdYB16hYfS7NtTn@public.gmane.org>
On Wed, Apr 06, 2016 at 22:07:39, Kalle Valo wrote:
>
> > More than that, wl1251 family is not officially supported via the
> > mainline Linux.
>
> I guess you mean not officially supported by TI? Because wl1251 driver
> has been in mainline for ages and reportedly working.
>
Correct.
Yaniv
> --
> Kalle Valo
--
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: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: David Miller @ 2016-04-06 19:30 UTC (permalink / raw)
To: tom; +Cc: ecree, herbert, alexander.duyck, aduyck, jesse, edumazet, netdev
In-Reply-To: <CALx6S36h4nZy10=dzfjgEgyXzokEfiteSNM_L3k4jFgg9-kgYA@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 6 Apr 2016 14:42:26 -0300
> On Wed, Apr 6, 2016 at 12:43 PM, David Miller <davem@davemloft.net> wrote:
>> From: Tom Herbert <tom@herbertland.com>
>> Date: Wed, 6 Apr 2016 10:53:52 -0300
>>
>>> Packets that are forwarded really should not be GRO'ed in the first
>>> place because of the loss of information and added latency.
>>
>> First of all GRO is supposed to be lossless, so please stop saying this
>> would be a reason to turn it off on a router.
>>
>> Second of all, the biggest piece of overhead is the routing lookup,
>> therefore GRO batching helps enormously with routing workloads, and
>> therefore is appropriate to be enabled on routers.
>>
>> Yes, I agree that for locally terminated stuff it helps more, but don't
>> turn this into a "GRO on routers, meh..." type argument. It simply is
>> not true at all.
>>
> GRO on routers will help in a limited case where there is little load
> and the traffic is nicely groomed high tput TCP connections. But for
> routers with significant load, handling large quantities other
> protocols like UDP, GRO is not necessarily helpful and presents a
> nondeterministic performance improvement. For instance, I cannot
> provision a router with any assumptions that GRO will be effective for
> any % of packets to save any % of CPU, we need to provision based
> purely on ability to forward by pps assuming no benefit from GRO.
Just because you cannot predict how effective a facility will be,
that doesn't mean you shouldn't use it at all.
^ permalink raw reply
* Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: David Miller @ 2016-04-06 19:39 UTC (permalink / raw)
To: paul
Cc: pabeni, linux-security-module, james.l.morris, agruenba, sds, fw,
netdev, selinux
In-Reply-To: <CAHC9VhT0444cEDKsfww7Yj22svSFOfY4ersVhh8up9ZrZ_8rng@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Wed, 6 Apr 2016 14:36:43 -0400
> On Wed, Apr 6, 2016 at 2:23 PM, David Miller <davem@davemloft.net> wrote:
>> From: Paul Moore <paul@paul-moore.com>
>> Date: Wed, 6 Apr 2016 10:07:27 -0400
>>
>>> "While marking the LSM hook structure doesn't directly affect the
>>> SELinux netfilter hooks, once we remove the ability to deregister the
>>> LSM hooks we will have no need to support deregistering netfilter
>>> hooks and I expect we will drop that functionality as well to help
>>> decrease the risk of tampering."
>>
>> This is not a reasonable postiion.
>>
>> The performance implications are non-trivial for using netfilter hooks
>> when they aren't actually needed.
>
> With all due respect, I think you've taken what I consider to be some
> unreasonable positions when it comes to the network stack and LSMs in
> the past. We have different perspectives and different priorities as
> a result, from my perspective the security advantage gained by
> eliminating the ability to disable SELinux at runtime is more
> important.
SELinux folks seem to get rather upset to people outright disabling
the facility, but many users still do exactly that.
In my opinion, it's uncompromising positions like the one you are
having here is part of the reason that issue will continue.
It is not AND, it's an OR, people want choice, and if you don't give
it to them they will find a way to achieve what they want with or
without your help. And you might not like what they come up with.
If distributions are turning SELinux on by default, then we have to
care about whather netfilter performance should suffer for facilities
which are unused.
^ permalink raw reply
* Re: [RFC PATCH 5/5] Add sample for adding simple drop program to link
From: Jesper Dangaard Brouer @ 2016-04-06 19:48 UTC (permalink / raw)
To: Brenden Blanco
Cc: davem, netdev, tom, alexei.starovoitov, Or Gerlitz, daniel,
john.fastabend, brouer
In-Reply-To: <1459560118-5582-6-git-send-email-bblanco@plumgrid.com>
I'm testing with this program and these patches, after getting past the
challenge of compiling the samples/bpf files ;-)
On Fri, 1 Apr 2016 18:21:58 -0700 Brenden Blanco <bblanco@plumgrid.com> wrote:
> Add a sample program that only drops packets at the
> BPF_PROG_TYPE_PHYS_DEV hook of a link. With the drop-only program,
> observed single core rate is ~14.6Mpps.
On my i7-4790K CPU @ 4.00GHz I'm seeing 9.7Mpps (single flow/cpu).
(generator: pktgen_sample03_burst_single_flow.sh)
# ./netdrvx1 $(</sys/class/net/mlx4p1/ifindex)
sh: /sys/kernel/debug/tracing/kprobe_events: No such file or directory
Success: Loaded file ./netdrvx1_kern.o
proto 17: 9776320 drops/s
These numbers are quite impressive. Compared to: sending it to local
socket that drop packets 1.7Mpps. Compared to: dropping with iptables
in "raw" table 3.7Mpps.
If I do multiple flows, via ./pktgen_sample05_flow_per_thread.sh
then I hit this strange 14.5Mpps limit (proto 17: 14505558 drops/s).
And the RX 4x CPUs are starting to NOT use 100% in softirq, they have
some cycles attributed to %idle. (I verified generator is sending at
24Mpps).
> Other tests were run, for instance without the dropcnt increment or
> without reading from the packet header, the packet rate was mostly
> unchanged.
If I change the program to not touch packet data (don't call
load_byte()) then the performance increase to 14.6Mpps (single
flow/cpu). And the RX CPU is mostly idle... mlx4_en_process_rx_cq()
and page alloc/free functions taking the time.
> $ perf record -a samples/bpf/netdrvx1 $(</sys/class/net/eth0/ifindex)
> proto 17: 14597724 drops/s
>
> ./pktgen_sample03_burst_single_flow.sh -i $DEV -d $IP -m $MAC -t 4
> Running... ctrl^C to stop
> Device: eth4@0
> Result: OK: 6486875(c6485849+d1026) usec, 23689465 (60byte,0frags)
> 3651906pps 1752Mb/sec (1752914880bps) errors: 0
> Device: eth4@1
> Result: OK: 6486874(c6485656+d1217) usec, 23689489 (60byte,0frags)
> 3651911pps 1752Mb/sec (1752917280bps) errors: 0
> Device: eth4@2
> Result: OK: 6486851(c6485730+d1120) usec, 23687853 (60byte,0frags)
> 3651672pps 1752Mb/sec (1752802560bps) errors: 0
> Device: eth4@3
> Result: OK: 6486879(c6485807+d1071) usec, 23688954 (60byte,0frags)
> 3651825pps 1752Mb/sec (1752876000bps) errors: 0
>
> perf report --no-children:
> 18.36% ksoftirqd/1 [mlx4_en] [k] mlx4_en_process_rx_cq
> 15.98% swapper [kernel.vmlinux] [k] poll_idle
> 12.71% ksoftirqd/1 [mlx4_en] [k] mlx4_en_alloc_frags
> 6.87% ksoftirqd/1 [mlx4_en] [k] mlx4_en_free_frag
> 4.20% ksoftirqd/1 [kernel.vmlinux] [k] get_page_from_freelist
> 4.09% swapper [mlx4_en] [k] mlx4_en_process_rx_cq
> 3.32% ksoftirqd/1 [kernel.vmlinux] [k] sk_load_byte_positive_offset
> 2.39% ksoftirqd/1 [mdio] [k] 0x00000000000074cd
> 2.23% swapper [mlx4_en] [k] mlx4_en_alloc_frags
> 2.20% ksoftirqd/1 [kernel.vmlinux] [k] free_pages_prepare
> 2.08% ksoftirqd/1 [mlx4_en] [k] mlx4_call_bpf
> 1.57% ksoftirqd/1 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
> 1.35% ksoftirqd/1 [mdio] [k] 0x00000000000074fa
> 1.09% ksoftirqd/1 [kernel.vmlinux] [k] free_one_page
> 1.02% ksoftirqd/1 [kernel.vmlinux] [k] bpf_map_lookup_elem
> 0.90% ksoftirqd/1 [kernel.vmlinux] [k] __alloc_pages_nodemask
> 0.88% swapper [kernel.vmlinux] [k] intel_idle
> 0.82% ksoftirqd/1 [mdio] [k] 0x00000000000074be
> 0.80% swapper [mlx4_en] [k] mlx4_en_free_frag
My picture (single flow/cpu) looks a little bit different:
+ 64.33% ksoftirqd/7 [kernel.vmlinux] [k] __bpf_prog_run
+ 9.60% ksoftirqd/7 [mlx4_en] [k] mlx4_en_alloc_frags
+ 7.71% ksoftirqd/7 [mlx4_en] [k] mlx4_en_process_rx_cq
+ 5.47% ksoftirqd/7 [mlx4_en] [k] mlx4_en_free_frag
+ 1.68% ksoftirqd/7 [kernel.vmlinux] [k] get_page_from_freelist
+ 1.52% ksoftirqd/7 [mlx4_en] [k] mlx4_call_bpf
+ 1.02% ksoftirqd/7 [kernel.vmlinux] [k] free_pages_prepare
+ 0.72% ksoftirqd/7 [mlx4_en] [k] mlx4_alloc_pages.isra.20
+ 0.70% ksoftirqd/7 [kernel.vmlinux] [k] __rcu_read_unlock
+ 0.65% ksoftirqd/7 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
On my i7-4790K CPU, I don't have DDIO, thus I assume this high cost in
__bpf_prog_run is due to a cache-miss on the packet data.
> machine specs:
> receiver - Intel E5-1630 v3 @ 3.70GHz
> sender - Intel E5645 @ 2.40GHz
> Mellanox ConnectX-3 @40G
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v2 1/2] sctp: compress bit-wide flags to a bitfield on sctp_sock
From: Joe Perches @ 2016-04-06 19:53 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, netdev; +Cc: Neil Horman, Vlad Yasevich, linux-sctp
In-Reply-To: <69a5ce012d9978ce73aade0004c5937964c54d61.1459952558.git.marcelo.leitner@gmail.com>
On Wed, 2016-04-06 at 14:53 -0300, Marcelo Ricardo Leitner wrote:
> It wastes space and gets worse as we add new flags, so convert bit-wide
> flags to a bitfield.
>
> Currently it already saves 4 bytes in sctp_sock, which are left as holes
> in it for now. The whole struct needs packing, which should be done in
> another patch.
>
> Note that do_auto_asconf cannot be merged, as explained in the comment
> before it.
>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
[]
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
[]
> @@ -210,14 +210,14 @@ struct sctp_sock {
> int user_frag;
>
> __u32 autoclose;
> - __u8 nodelay;
> - __u8 disable_fragments;
> - __u8 v4mapped;
> - __u8 frag_interleave;
> __u32 adaptation_ind;
> __u32 pd_point;
> - __u8 recvrcvinfo;
> - __u8 recvnxtinfo;
> + __u16 nodelay:1,
> + disable_fragments:1,
> + v4mapped:1,
> + frag_interleave:1,
> + recvrcvinfo:1,
> + recvnxtinfo:1;
Might as well make this __u32 as the next field would be
aligned on an atomic_t
It might be better if these fields didn't use the __ prefix.
^ permalink raw reply
* Re: [PATCH v2 1/2] sctp: compress bit-wide flags to a bitfield on sctp_sock
From: David Miller @ 2016-04-06 19:57 UTC (permalink / raw)
To: joe; +Cc: marcelo.leitner, netdev, nhorman, vyasevich, linux-sctp
In-Reply-To: <1459972404.6715.65.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Wed, 06 Apr 2016 12:53:24 -0700
> On Wed, 2016-04-06 at 14:53 -0300, Marcelo Ricardo Leitner wrote:
>> It wastes space and gets worse as we add new flags, so convert bit-wide
>> flags to a bitfield.
>>
>> Currently it already saves 4 bytes in sctp_sock, which are left as holes
>> in it for now. The whole struct needs packing, which should be done in
>> another patch.
>>
>> Note that do_auto_asconf cannot be merged, as explained in the comment
>> before it.
>>
>> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>> ---
> []
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> []
>> @@ -210,14 +210,14 @@ struct sctp_sock {
>> int user_frag;
>>
>> __u32 autoclose;
>> - __u8 nodelay;
>> - __u8 disable_fragments;
>> - __u8 v4mapped;
>> - __u8 frag_interleave;
>> __u32 adaptation_ind;
>> __u32 pd_point;
>> - __u8 recvrcvinfo;
>> - __u8 recvnxtinfo;
>> + __u16 nodelay:1,
>> + disable_fragments:1,
>> + v4mapped:1,
>> + frag_interleave:1,
>> + recvrcvinfo:1,
>> + recvnxtinfo:1;
>
> Might as well make this __u32 as the next field would be
> aligned on an atomic_t
>
> It might be better if these fields didn't use the __ prefix.
Indeed, this isn't in a UAPI file so __ prefixed types really aren't
appropriate.
^ permalink raw reply
* Re: [RFC PATCH 5/5] Add sample for adding simple drop program to link
From: Jesper Dangaard Brouer @ 2016-04-06 20:01 UTC (permalink / raw)
To: Brenden Blanco
Cc: davem, netdev, tom, alexei.starovoitov, Or Gerlitz, daniel,
john.fastabend, brouer
In-Reply-To: <20160406214848.7568235b@redhat.com>
On Wed, 6 Apr 2016 21:48:48 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> I'm testing with this program and these patches, after getting past the
> challenge of compiling the samples/bpf files ;-)
>
>
> On Fri, 1 Apr 2016 18:21:58 -0700 Brenden Blanco <bblanco@plumgrid.com> wrote:
>
> > Add a sample program that only drops packets at the
> > BPF_PROG_TYPE_PHYS_DEV hook of a link. With the drop-only program,
> > observed single core rate is ~14.6Mpps.
>
> On my i7-4790K CPU @ 4.00GHz I'm seeing 9.7Mpps (single flow/cpu).
> (generator: pktgen_sample03_burst_single_flow.sh)
>
> # ./netdrvx1 $(</sys/class/net/mlx4p1/ifindex)
> sh: /sys/kernel/debug/tracing/kprobe_events: No such file or directory
> Success: Loaded file ./netdrvx1_kern.o
> proto 17: 9776320 drops/s
>
> These numbers are quite impressive. Compared to: sending it to local
> socket that drop packets 1.7Mpps. Compared to: dropping with iptables
> in "raw" table 3.7Mpps.
>
> If I do multiple flows, via ./pktgen_sample05_flow_per_thread.sh
> then I hit this strange 14.5Mpps limit (proto 17: 14505558 drops/s).
> And the RX 4x CPUs are starting to NOT use 100% in softirq, they have
> some cycles attributed to %idle. (I verified generator is sending at
> 24Mpps).
>
>
> > Other tests were run, for instance without the dropcnt increment or
> > without reading from the packet header, the packet rate was mostly
> > unchanged.
>
> If I change the program to not touch packet data (don't call
> load_byte()) then the performance increase to 14.6Mpps (single
> flow/cpu). And the RX CPU is mostly idle... mlx4_en_process_rx_cq()
> and page alloc/free functions taking the time.
>
> > $ perf record -a samples/bpf/netdrvx1 $(</sys/class/net/eth0/ifindex)
> > proto 17: 14597724 drops/s
> >
> > ./pktgen_sample03_burst_single_flow.sh -i $DEV -d $IP -m $MAC -t 4
> > Running... ctrl^C to stop
> > Device: eth4@0
> > Result: OK: 6486875(c6485849+d1026) usec, 23689465 (60byte,0frags)
> > 3651906pps 1752Mb/sec (1752914880bps) errors: 0
> > Device: eth4@1
> > Result: OK: 6486874(c6485656+d1217) usec, 23689489 (60byte,0frags)
> > 3651911pps 1752Mb/sec (1752917280bps) errors: 0
> > Device: eth4@2
> > Result: OK: 6486851(c6485730+d1120) usec, 23687853 (60byte,0frags)
> > 3651672pps 1752Mb/sec (1752802560bps) errors: 0
> > Device: eth4@3
> > Result: OK: 6486879(c6485807+d1071) usec, 23688954 (60byte,0frags)
> > 3651825pps 1752Mb/sec (1752876000bps) errors: 0
> >
> > perf report --no-children:
> > 18.36% ksoftirqd/1 [mlx4_en] [k] mlx4_en_process_rx_cq
> > 15.98% swapper [kernel.vmlinux] [k] poll_idle
> > 12.71% ksoftirqd/1 [mlx4_en] [k] mlx4_en_alloc_frags
> > 6.87% ksoftirqd/1 [mlx4_en] [k] mlx4_en_free_frag
> > 4.20% ksoftirqd/1 [kernel.vmlinux] [k] get_page_from_freelist
> > 4.09% swapper [mlx4_en] [k] mlx4_en_process_rx_cq
> > 3.32% ksoftirqd/1 [kernel.vmlinux] [k] sk_load_byte_positive_offset
> > 2.39% ksoftirqd/1 [mdio] [k] 0x00000000000074cd
> > 2.23% swapper [mlx4_en] [k] mlx4_en_alloc_frags
> > 2.20% ksoftirqd/1 [kernel.vmlinux] [k] free_pages_prepare
> > 2.08% ksoftirqd/1 [mlx4_en] [k] mlx4_call_bpf
> > 1.57% ksoftirqd/1 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
> > 1.35% ksoftirqd/1 [mdio] [k] 0x00000000000074fa
> > 1.09% ksoftirqd/1 [kernel.vmlinux] [k] free_one_page
> > 1.02% ksoftirqd/1 [kernel.vmlinux] [k] bpf_map_lookup_elem
> > 0.90% ksoftirqd/1 [kernel.vmlinux] [k] __alloc_pages_nodemask
> > 0.88% swapper [kernel.vmlinux] [k] intel_idle
> > 0.82% ksoftirqd/1 [mdio] [k] 0x00000000000074be
> > 0.80% swapper [mlx4_en] [k] mlx4_en_free_frag
>
> My picture (single flow/cpu) looks a little bit different:
>
> + 64.33% ksoftirqd/7 [kernel.vmlinux] [k] __bpf_prog_run
> + 9.60% ksoftirqd/7 [mlx4_en] [k] mlx4_en_alloc_frags
> + 7.71% ksoftirqd/7 [mlx4_en] [k] mlx4_en_process_rx_cq
> + 5.47% ksoftirqd/7 [mlx4_en] [k] mlx4_en_free_frag
> + 1.68% ksoftirqd/7 [kernel.vmlinux] [k] get_page_from_freelist
> + 1.52% ksoftirqd/7 [mlx4_en] [k] mlx4_call_bpf
> + 1.02% ksoftirqd/7 [kernel.vmlinux] [k] free_pages_prepare
> + 0.72% ksoftirqd/7 [mlx4_en] [k] mlx4_alloc_pages.isra.20
> + 0.70% ksoftirqd/7 [kernel.vmlinux] [k] __rcu_read_unlock
> + 0.65% ksoftirqd/7 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
>
> On my i7-4790K CPU, I don't have DDIO, thus I assume this high cost in
> __bpf_prog_run is due to a cache-miss on the packet data.
Before someone else point out the obvious... I forgot to enable JIT.
Enable it::
# echo 1 > /proc/sys/net/core/bpf_jit_enable
Performance increased to: 10.8Mpps (proto 17: 10819446 drops/s)
Samples: 51K of event 'cycles', Event count (approx.): 56775706510
Overhead Command Shared Object Symbol
+ 55.90% ksoftirqd/7 [kernel.vmlinux] [k] sk_load_byte_positive_offset
+ 10.71% ksoftirqd/7 [mlx4_en] [k] mlx4_en_alloc_frags
+ 8.26% ksoftirqd/7 [mlx4_en] [k] mlx4_en_process_rx_cq
+ 5.94% ksoftirqd/7 [mlx4_en] [k] mlx4_en_free_frag
+ 2.04% ksoftirqd/7 [kernel.vmlinux] [k] get_page_from_freelist
+ 2.03% ksoftirqd/7 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
+ 1.42% ksoftirqd/7 [mlx4_en] [k] mlx4_call_bpf
+ 1.04% ksoftirqd/7 [kernel.vmlinux] [k] free_pages_prepare
+ 1.03% ksoftirqd/7 [kernel.vmlinux] [k] __rcu_read_unlock
+ 0.97% ksoftirqd/7 [mlx4_en] [k] mlx4_alloc_pages.isra.20
+ 0.95% ksoftirqd/7 [devlink] [k] 0x0000000000005f87
+ 0.58% ksoftirqd/7 [devlink] [k] 0x0000000000005f8f
+ 0.49% ksoftirqd/7 [kernel.vmlinux] [k] __free_pages_ok
+ 0.47% ksoftirqd/7 [kernel.vmlinux] [k] __rcu_read_lock
+ 0.46% ksoftirqd/7 [kernel.vmlinux] [k] free_one_page
+ 0.38% ksoftirqd/7 [kernel.vmlinux] [k] net_rx_action
+ 0.36% ksoftirqd/7 [kernel.vmlinux] [k] bpf_map_lookup_elem
+ 0.36% ksoftirqd/7 [kernel.vmlinux] [k] __mod_zone_page_state
+ 0.34% ksoftirqd/7 [kernel.vmlinux] [k] __alloc_pages_nodemask
+ 0.32% ksoftirqd/7 [kernel.vmlinux] [k] _raw_spin_lock
+ 0.31% ksoftirqd/7 [devlink] [k] 0x0000000000005f0a
+ 0.29% ksoftirqd/7 [kernel.vmlinux] [k] next_zones_zonelist
It is a very likely cache-miss in sk_load_byte_positive_offset().
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCHv2 net 1/3] samples/bpf: Fix build breakage with map_perf_test_user.c
From: David Miller @ 2016-04-06 20:01 UTC (permalink / raw)
To: naveen.n.rao; +Cc: linux-kernel, linuxppc-dev, netdev, ast, daniel, ananth, mpe
In-Reply-To: <5ab5eec91d2d0bc7f221d714ef84afac83b2604b.1459789086.git.naveen.n.rao@linux.vnet.ibm.com>
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Date: Mon, 4 Apr 2016 22:31:32 +0530
> Building BPF samples is failing with the below error:
...
> Fix this by including the necessary header file.
>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 net 3/3] samples/bpf: Enable powerpc support
From: David Miller @ 2016-04-06 20:02 UTC (permalink / raw)
To: naveen.n.rao; +Cc: linux-kernel, linuxppc-dev, netdev, ast, daniel, ananth, mpe
In-Reply-To: <28d2e09a7db94a0a71b3222b3e5ffacb0d4a8dd7.1459789086.git.naveen.n.rao@linux.vnet.ibm.com>
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Date: Mon, 4 Apr 2016 22:31:34 +0530
> Add the necessary definitions for building bpf samples on ppc.
>
> Since ppc doesn't store function return address on the stack, modify how
> PT_REGS_RET() and PT_REGS_FP() work.
>
> Also, introduce PT_REGS_IP() to access the instruction pointer.
>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 net 2/3] samples/bpf: Use llc in PATH, rather than a hardcoded value
From: David Miller @ 2016-04-06 20:02 UTC (permalink / raw)
To: naveen.n.rao; +Cc: linux-kernel, linuxppc-dev, netdev, ast, daniel, ananth, mpe
In-Reply-To: <000e23c21f475e7106c74a83eb6226c4cb8d4a14.1459789086.git.naveen.n.rao@linux.vnet.ibm.com>
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Date: Mon, 4 Apr 2016 22:31:33 +0530
> While at it, remove the generation of .s files and fix some typos in the
> related comment.
>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH 5/5] Add sample for adding simple drop program to link
From: Daniel Borkmann @ 2016-04-06 20:03 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Brenden Blanco
Cc: davem, netdev, tom, alexei.starovoitov, Or Gerlitz,
john.fastabend
In-Reply-To: <20160406214848.7568235b@redhat.com>
On 04/06/2016 09:48 PM, Jesper Dangaard Brouer wrote:
>
> I'm testing with this program and these patches, after getting past the
> challenge of compiling the samples/bpf files ;-)
>
> On Fri, 1 Apr 2016 18:21:58 -0700 Brenden Blanco <bblanco@plumgrid.com> wrote:
>
>> Add a sample program that only drops packets at the
>> BPF_PROG_TYPE_PHYS_DEV hook of a link. With the drop-only program,
>> observed single core rate is ~14.6Mpps.
>
> On my i7-4790K CPU @ 4.00GHz I'm seeing 9.7Mpps (single flow/cpu).
> (generator: pktgen_sample03_burst_single_flow.sh)
>
> # ./netdrvx1 $(</sys/class/net/mlx4p1/ifindex)
> sh: /sys/kernel/debug/tracing/kprobe_events: No such file or directory
> Success: Loaded file ./netdrvx1_kern.o
> proto 17: 9776320 drops/s
>
> These numbers are quite impressive. Compared to: sending it to local
> socket that drop packets 1.7Mpps. Compared to: dropping with iptables
> in "raw" table 3.7Mpps.
>
> If I do multiple flows, via ./pktgen_sample05_flow_per_thread.sh
> then I hit this strange 14.5Mpps limit (proto 17: 14505558 drops/s).
> And the RX 4x CPUs are starting to NOT use 100% in softirq, they have
> some cycles attributed to %idle. (I verified generator is sending at
> 24Mpps).
>
>> Other tests were run, for instance without the dropcnt increment or
>> without reading from the packet header, the packet rate was mostly
>> unchanged.
>
> If I change the program to not touch packet data (don't call
> load_byte()) then the performance increase to 14.6Mpps (single
> flow/cpu). And the RX CPU is mostly idle... mlx4_en_process_rx_cq()
> and page alloc/free functions taking the time.
>
>> $ perf record -a samples/bpf/netdrvx1 $(</sys/class/net/eth0/ifindex)
>> proto 17: 14597724 drops/s
>>
>> ./pktgen_sample03_burst_single_flow.sh -i $DEV -d $IP -m $MAC -t 4
>> Running... ctrl^C to stop
>> Device: eth4@0
>> Result: OK: 6486875(c6485849+d1026) usec, 23689465 (60byte,0frags)
>> 3651906pps 1752Mb/sec (1752914880bps) errors: 0
>> Device: eth4@1
>> Result: OK: 6486874(c6485656+d1217) usec, 23689489 (60byte,0frags)
>> 3651911pps 1752Mb/sec (1752917280bps) errors: 0
>> Device: eth4@2
>> Result: OK: 6486851(c6485730+d1120) usec, 23687853 (60byte,0frags)
>> 3651672pps 1752Mb/sec (1752802560bps) errors: 0
>> Device: eth4@3
>> Result: OK: 6486879(c6485807+d1071) usec, 23688954 (60byte,0frags)
>> 3651825pps 1752Mb/sec (1752876000bps) errors: 0
>>
>> perf report --no-children:
>> 18.36% ksoftirqd/1 [mlx4_en] [k] mlx4_en_process_rx_cq
>> 15.98% swapper [kernel.vmlinux] [k] poll_idle
>> 12.71% ksoftirqd/1 [mlx4_en] [k] mlx4_en_alloc_frags
>> 6.87% ksoftirqd/1 [mlx4_en] [k] mlx4_en_free_frag
>> 4.20% ksoftirqd/1 [kernel.vmlinux] [k] get_page_from_freelist
>> 4.09% swapper [mlx4_en] [k] mlx4_en_process_rx_cq
>> 3.32% ksoftirqd/1 [kernel.vmlinux] [k] sk_load_byte_positive_offset
>> 2.39% ksoftirqd/1 [mdio] [k] 0x00000000000074cd
>> 2.23% swapper [mlx4_en] [k] mlx4_en_alloc_frags
>> 2.20% ksoftirqd/1 [kernel.vmlinux] [k] free_pages_prepare
>> 2.08% ksoftirqd/1 [mlx4_en] [k] mlx4_call_bpf
>> 1.57% ksoftirqd/1 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
>> 1.35% ksoftirqd/1 [mdio] [k] 0x00000000000074fa
>> 1.09% ksoftirqd/1 [kernel.vmlinux] [k] free_one_page
>> 1.02% ksoftirqd/1 [kernel.vmlinux] [k] bpf_map_lookup_elem
>> 0.90% ksoftirqd/1 [kernel.vmlinux] [k] __alloc_pages_nodemask
>> 0.88% swapper [kernel.vmlinux] [k] intel_idle
>> 0.82% ksoftirqd/1 [mdio] [k] 0x00000000000074be
>> 0.80% swapper [mlx4_en] [k] mlx4_en_free_frag
>
> My picture (single flow/cpu) looks a little bit different:
>
> + 64.33% ksoftirqd/7 [kernel.vmlinux] [k] __bpf_prog_run
Looks like 'echo 1 > /proc/sys/net/core/bpf_jit_enable' is missing?
> + 9.60% ksoftirqd/7 [mlx4_en] [k] mlx4_en_alloc_frags
> + 7.71% ksoftirqd/7 [mlx4_en] [k] mlx4_en_process_rx_cq
> + 5.47% ksoftirqd/7 [mlx4_en] [k] mlx4_en_free_frag
> + 1.68% ksoftirqd/7 [kernel.vmlinux] [k] get_page_from_freelist
> + 1.52% ksoftirqd/7 [mlx4_en] [k] mlx4_call_bpf
> + 1.02% ksoftirqd/7 [kernel.vmlinux] [k] free_pages_prepare
> + 0.72% ksoftirqd/7 [mlx4_en] [k] mlx4_alloc_pages.isra.20
> + 0.70% ksoftirqd/7 [kernel.vmlinux] [k] __rcu_read_unlock
> + 0.65% ksoftirqd/7 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
>
> On my i7-4790K CPU, I don't have DDIO, thus I assume this high cost in
> __bpf_prog_run is due to a cache-miss on the packet data.
>
>> machine specs:
>> receiver - Intel E5-1630 v3 @ 3.70GHz
>> sender - Intel E5645 @ 2.40GHz
>> Mellanox ConnectX-3 @40G
>
^ permalink raw reply
* Re: [Patch net] net_sched: fix a memory leak in tc action
From: David Miller @ 2016-04-06 20:04 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, dvyukov, jhs
In-Reply-To: <1459791168-16675-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 4 Apr 2016 10:32:48 -0700
> Fixes: ddf97ccdd7cb ("net_sched: add network namespace support for tc actions")
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Tested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks Cong.
^ permalink raw reply
* Re: af_packet: tone down the Tx-ring unsupported spew.
From: David Miller @ 2016-04-06 20:05 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20160404191150.GA7224@codemonkey.org.uk>
From: Dave Jones <davej@codemonkey.org.uk>
Date: Mon, 4 Apr 2016 15:11:50 -0400
> Trinity and other fuzzers can hit this WARN on far too easily,
> resulting in a tainted kernel that hinders automated fuzzing.
>
> Replace it with a rate-limited printk.
>
> Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Looks good, thanks Dave.
^ 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