> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Sunday, July 29, 2018 11:48 AM
> To: Vakul Garg
> Cc: netdev@vger.kernel.org; bor...@mellanox.com;
> avia...@mellanox.com; davejwat...@fb.com
> Subject: Re: [net-next v6 1/2] net/tls: Use socket data_ready ca
From: Vakul Garg
Date: Sun, 29 Jul 2018 06:01:29 +
> Could you please correct me if my counter-reasoning behind changing
> the socket callback is wrong?
Ok, after stufying the code a bit I agree with your analysis.
From: Li RongQing
Date: Fri, 27 Jul 2018 16:03:57 +0800
> The size of struct cpumask varies with CONFIG_NR_CPUS, some config
> CONFIG_NR_CPUS is very larger, like 5120, struct cpumask will take
> 640 bytes, if there is thousands of flows, it will take lots of
> memory
>
> cpu_used_mask has two p
Hi David
Could you please correct me if my counter-reasoning behind changing the socket
callback is wrong?
Thanks & Regards
Vakul
> -Original Message-
> From: Vakul Garg
> Sent: Wednesday, July 25, 2018 11:22 AM
> To: David Miller
> Cc: netdev@vger.kernel.org; bor...@mellanox.com;
> a
From: Doron Roberts-Kedes
Date: Thu, 26 Jul 2018 07:59:34 -0700
> This series fixes the improper iov_iter_revert introcded in
> "tls: Fix zerocopy_from_iter iov handling".
>
> Changes from v1:
> - call iov_iter_revert inside zerocopy_from_iter
Series applied, thank you.
From: Neal Cardwell
Date: Fri, 27 Jul 2018 17:19:12 -0400
> For some very small BDPs (with just a few packets) there was a
> quantization effect where the target number of packets in flight
> during the super-unity-gain (1.25x) phase of gain cycling was
> implicitly truncated to a number of packe
Hi Paolo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Paolo-Abeni/TC-refactor-act_mirred-packets-re-injection/20180729-102154
config: x86_64-randconfig-u0-07291027 (attached as .config)
comp
From: Daniel Borkmann
Date: Sun, 29 Jul 2018 04:22:24 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) API fixes for libbpf's BTF mapping of map key/value types in order
>to make them compatible with iproute2's BPF_ANNOTATE_KV_PAI
Hi Paolo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Paolo-Abeni/TC-refactor-act_mirred-packets-re-injection/20180729-102154
config: i386-randconfig-n0-201829 (attached as .config)
compiler: gcc-
Hi Paolo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Paolo-Abeni/TC-refactor-act_mirred-packets-re-injection/20180729-102154
config: xtensa-allyesconfig (attached as .config)
compiler: xten
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) API fixes for libbpf's BTF mapping of map key/value types in order
to make them compatible with iproute2's BPF_ANNOTATE_KV_PAIR()
markings, from Martin.
2) Fix AF_XDP to not report POLL
From: Lorenzo Bianconi
Date: Fri, 27 Jul 2018 18:15:46 +0200
> Remove BUG_ON() from fib_compute_spec_dst routine and check
> in_dev pointer during flowi4 data structure initialization.
> fib_compute_spec_dst routine can be run concurrently with device removal
> where ip_ptr net_device pointer is
From: Govindarajulu Varadarajan
Date: Fri, 27 Jul 2018 11:19:29 -0700
> When driver gets notification for mtu change, driver does not handle it for
> all RQs. It handles only RQ[0].
>
> Fix is to use enic_change_mtu() interface to change mtu for vf.
>
> Signed-off-by: Govindarajulu Varadarajan
The meter code would create an entry for each new meter. However, it
would not set the meter id in the new entry, so every meter would appear
to have a meter id of zero. This commit properly sets the meter id when
adding the entry.
Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure")
Si
From: Jakub Kicinski
Date: Fri, 27 Jul 2018 20:56:52 -0700
> From: John Hurley
>
> Function nfp_flower_repr_get_type_and_port expects an enum nfp_repr_type
> return value but, if the repr type is unknown, returns a value of type
> enum nfp_flower_cmsg_port_type. This means that if FW encodes t
sch_skbprio is a qdisc that prioritizes packets according to their skb->priority
field. Under congestion, it drops already-enqueued lower priority packets to
make space available for higher priority packets. Skbprio was conceived as a
solution for denial-of-service defenses that need to route packe
On 07/28/2018 05:28 PM, Taehee Yoo wrote:
> bpf_parse_prog() is protected by rcu_read_lock().
> so that GFP_KERNEL is not allowed in the bpf_parse_prog().
>
> [51015.579396] =
> [51015.579418] WARNING: suspicious RCU usage
> [51015.579444] 4.18.0-rc6+ #208 Not tainted
>
On 07/28/2018 01:11 AM, Yonghong Song wrote:
> I hit the following problem when I tried to use bpftool
> to dump a percpu array.
>
> $ sudo ./bpftool map show
> 61: percpu_array name stub flags 0x0
> key 4B value 4B max_entries 1 memlock 4096B
> ...
> $ sudo ./bpftool map dump
On Fri, Jul 27, 2018 at 1:03 AM, Li RongQing wrote:
> The size of struct cpumask varies with CONFIG_NR_CPUS, some config
> CONFIG_NR_CPUS is very larger, like 5120, struct cpumask will take
> 640 bytes, if there is thousands of flows, it will take lots of
> memory
>
I am fine with removing cpumask
The len > skb_headlen(skb) cannot be used as a maximum upper bound
for the packet length since it does not have any relation to the full
linear packet length when filtering is used from upper layers (e.g.
in case of reuseport BPF programs) as by then skb->data, skb->len
already got mangled through
On Sat, Jul 28, 2018 at 10:20 AM Cong Wang wrote:
>
> On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko wrote:
> >
> > From: Jiri Pirko
> >
> > In case a chain is empty and not explicitly created by a user,
> > such chain should not exist. The only exception is if there is
> > an action "goto chain" p
On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko wrote:
>
> From: Jiri Pirko
>
> In case a chain is empty and not explicitly created by a user,
> such chain should not exist. The only exception is if there is
> an action "goto chain" pointing to it. In that case, don't show the
> chain in the dump. Tr
On Thu, Jul 26, 2018 at 07:00:20AM -0700, Alexander Duyck wrote:
> On Thu, Jul 26, 2018 at 12:14 AM, Jiri Pirko wrote:
> > Thu, Jul 26, 2018 at 02:43:59AM CEST, jakub.kicin...@netronome.com wrote:
> >>On Wed, 25 Jul 2018 08:23:26 -0700, Alexander Duyck wrote:
> >>> On Wed, Jul 25, 2018 at 5:31 AM,
bpf_parse_prog() is protected by rcu_read_lock().
so that GFP_KERNEL is not allowed in the bpf_parse_prog().
[51015.579396] =
[51015.579418] WARNING: suspicious RCU usage
[51015.579444] 4.18.0-rc6+ #208 Not tainted
[51015.579464] -
[51015.579
body {height: 100%; color:#00; font-size:12pt; font-family:arial,
helvetica, sans-serif;}
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere
Informationen
Do you need a loan of any kind? If Yes email us now for more info
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere
Informationen
Do you need a loan of any kind? If Yes email us now for more info
26 matches
Mail list logo
