[PATCH v4 net-next 4/9] net: core: Another step of skb receive list processing

netif_receive_skb_list_internal() now processes a list and hands it on to the next function. Signed-off-by: Edward Cree --- net/core/dev.c | 61 +- 1 file changed, 56 insertions(+), 5 deletions(-) diff --git a/net/core/dev.c b/net/core

[PATCH v4 net-next 1/9] net: core: trivial netif_receive_skb_list() entry point

Just calls netif_receive_skb() in a loop. Signed-off-by: Edward Cree --- include/linux/netdevice.h | 1 + net/core/dev.c| 19 +++ 2 files changed, 20 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index c6b377a15869..e104b2e4a735

[PATCH v4 net-next 3/9] net: core: unwrap skb list receive slightly further

Signed-off-by: Edward Cree --- include/trace/events/net.h | 7 +++ net/core/dev.c | 4 +++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/include/trace/events/net.h b/include/trace/events/net.h index 9c886739246a..00aa72ce0e7c 100644 --- a/include/trace/events

[PATCH v4 net-next 0/9] Handle multiple received packets at each stage

.kernel.org/netconf2018_files/EdwardCree_netconf2018.pdf Edward Cree (9): net: core: trivial netif_receive_skb_list() entry point sfc: batch up RX delivery net: core: unwrap skb list receive slightly further net: core: Another step of skb receive list processing net: core: another layer of lists, around P

Re: [PATCH v3 net-next 7/9] net: ipv4: listified version of ip_rcv

On 29/06/18 23:08, kbuild test robot wrote: >net//ipv4/ip_input.c: In function 'ip_sublist_rcv': >>> net//ipv4/ip_input.c:524:14: warning: passing argument 6 of 'NF_HOOK_LIST' >>> from incompatible pointer type >head, dev, NULL, ip_rcv_finish); > ^ >In file

[PATCH v3 net-next 9/9] net: don't bother calling list RX functions on empty lists

Generally the check should be very cheap, as the sk_buff_head is in cache. Signed-off-by: Edward Cree --- net/core/dev.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 4c5ebfab9bc8..d6084b0cd9ce 100644 --- a/net/core/dev.c +++ b

[PATCH v3 net-next 6/9] net: core: propagate SKB lists through packet_type lookup

in ptype_base[hash of skb->protocol]. Signed-off-by: Edward Cree --- net/core/dev.c | 72 +++--- 1 file changed, 64 insertions(+), 8 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index d2454678bc82..edd67b1f1e12 100644 --- a/net/core/de

[PATCH v3 net-next 7/9] net: ipv4: listified version of ip_rcv

to cause out-of-order receives, so presumably this is considered OK. Signed-off-by: Edward Cree --- include/linux/netdevice.h | 3 +++ include/linux/netfilter.h | 25 + include/net/ip.h | 2 ++ net/core/dev.c| 8 +++--- net/ipv4/af_inet.c| 1

[PATCH v3 net-next 8/9] net: ipv4: listify ip_rcv_finish

itting on protocol changes). Signed-off-by: Edward Cree --- net/ipv4/ip_input.c | 54 +++-- 1 file changed, 48 insertions(+), 6 deletions(-) diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c index 914240830bdf..24b9b0210aeb 100644 --- a/ne

[PATCH v3 net-next 5/9] net: core: another layer of lists, around PF_MEMALLOC skb handling

First example of a layer splitting the list (rather than merely taking individual packets off it). Involves new list.h function, list_cut_before(), like list_cut_position() but cuts on the other side of the given entry. Signed-off-by: Edward Cree --- include/linux/list.h | 30

[PATCH v3 net-next 4/9] net: core: Another step of skb receive list processing

netif_receive_skb_list_internal() now processes a list and hands it on to the next function. Signed-off-by: Edward Cree --- net/core/dev.c | 61 +- 1 file changed, 56 insertions(+), 5 deletions(-) diff --git a/net/core/dev.c b/net/core

[PATCH v3 net-next 2/9] sfc: batch up RX delivery

Improves packet rate of 1-byte UDP receives by up to 10%. Signed-off-by: Edward Cree --- drivers/net/ethernet/sfc/efx.c| 12 drivers/net/ethernet/sfc/net_driver.h | 3 +++ drivers/net/ethernet/sfc/rx.c | 7 ++- 3 files changed, 21 insertions(+), 1 deletion

[PATCH v3 net-next 3/9] net: core: unwrap skb list receive slightly further

Signed-off-by: Edward Cree --- include/trace/events/net.h | 7 +++ net/core/dev.c | 4 +++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/include/trace/events/net.h b/include/trace/events/net.h index 9c886739246a..00aa72ce0e7c 100644 --- a/include/trace/events

[PATCH v3 net-next 1/9] net: core: trivial netif_receive_skb_list() entry point

Just calls netif_receive_skb() in a loop. Signed-off-by: Edward Cree --- include/linux/netdevice.h | 1 + net/core/dev.c| 19 +++ 2 files changed, 20 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index c6b377a15869..e104b2e4a735

[PATCH v3 net-next 0/9] Handle multiple received packets at each stage

12), though it doesn't seem to help (see above). * Extended testing to cover software firewalls / netfilter etc. [1] http://vger.kernel.org/netconf2018_files/DavidMiller_netconf2018.pdf [2] http://vger.kernel.org/netconf2018_files/EdwardCree_netconf2018.pdf Edward Cree (9): net: core: trivial n

Re: [RFC PATCH v2 net-next 06/12] net: core: propagate SKB lists through packet_type lookup

On 27/06/18 17:00, Willem de Bruijn wrote: > On Wed, Jun 27, 2018 at 10:49 AM Edward Cree wrote: >> On 27/06/18 15:36, Willem de Bruijn wrote: >>> Also, this function does more than just process network taps. >> This is true, but naming things is hard, and I couldn't thin

Re: [RFC PATCH v2 net-next 06/12] net: core: propagate SKB lists through packet_type lookup

On 27/06/18 15:36, Willem de Bruijn wrote: > On Tue, Jun 26, 2018 at 8:19 PM Edward Cree wrote: >> __netif_receive_skb_taps() does a depressingly large amount of per-packet >> work that can't easily be listified, because the another_round looping >> makes it nontrivial to

Re: [RFC PATCH v2 net-next 01/12] net: core: trivial netif_receive_skb_list() entry point

On 27/06/18 01:06, Eric Dumazet wrote: > On 06/26/2018 11:17 AM, Edward Cree wrote: >> Just calls netif_receive_skb() in a loop. > ... > >> +void netif_receive_skb_list(struct sk_buff_head *list) > > Please use a standard list_head and standard list operators. > >

[RFC PATCH v2 net-next 12/12] net: listify jited Generic XDP processing on x86_64

as a parameter instead of calculating it inside the loop. This is safe because BPF execution is not preemptible, so the percpu variable can't get moved while we're using it. Signed-off-by: Edward Cree --- arch/x86/net/bpf_jit_comp.c | 164 include

[RFC PATCH v2 net-next 10/12] net: listify Generic XDP processing, part 1

Deals with all the pre- and post-amble to the BPF program itself, which is still called one packet at a time. Involves some fiddly percpu variables to cope with XDP_REDIRECT handling. Signed-off-by: Edward Cree --- include/linux/filter.h | 10 +++ net/core/dev.c | 165

[RFC PATCH v2 net-next 11/12] net: listify Generic XDP processing, part 2

of the extra indirect calls. Signed-off-by: Edward Cree --- include/linux/filter.h | 38 +- kernel/bpf/core.c | 26 ++ net/core/dev.c | 19 --- 3 files changed, 63 insertions(+), 20 deletions(-) diff --git

[RFC PATCH v2 net-next 09/12] net: don't bother calling list RX functions on empty lists

Generally the check should be very cheap, as the sk_buff_head is in cache. Signed-off-by: Edward Cree --- net/core/dev.c | 8 ++-- net/ipv4/ip_input.c | 2 ++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index f0eb00e9fb57..11f80d4502b9

[RFC PATCH v2 net-next 08/12] net: ipv4: listify ip_rcv_finish

itting on protocol changes). Signed-off-by: Edward Cree --- net/ipv4/ip_input.c | 58 - 1 file changed, 53 insertions(+), 5 deletions(-) diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c index 7a8af8ff3f07..63d4dfdb1766 100644 --- a/ne

[RFC PATCH v2 net-next 07/12] net: ipv4: listified version of ip_rcv

to cause out-of-order receives, so presumably this is considered OK. Signed-off-by: Edward Cree --- include/linux/netdevice.h | 3 ++ include/linux/netfilter.h | 27 + include/net/ip.h | 2 ++ net/core/dev.c| 11 +-- net/ipv4/af_inet.c| 1

[RFC PATCH v2 net-next 06/12] net: core: propagate SKB lists through packet_type lookup

in ptype_base[hash of skb->protocol]. Signed-off-by: Edward Cree --- include/trace/events/net.h | 7 +++ net/core/dev.c | 138 - 2 files changed, 105 insertions(+), 40 deletions(-) diff --git a/include/trace/events/net.h b/include/trace/eve

[RFC PATCH v2 net-next 04/12] net: core: Another step of skb receive list processing

netif_receive_skb_list_internal() now processes a list and hands it on to the next function. Signed-off-by: Edward Cree --- net/core/dev.c | 73 ++ 1 file changed, 69 insertions(+), 4 deletions(-) diff --git a/net/core/dev.c b/net/core

[RFC PATCH v2 net-next 05/12] net: core: another layer of lists, around PF_MEMALLOC skb handling

First example of a layer splitting the list (rather than merely taking individual packets off it). Signed-off-by: Edward Cree --- net/core/dev.c | 46 ++ 1 file changed, 38 insertions(+), 8 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c

[RFC PATCH v2 net-next 03/12] net: core: unwrap skb list receive slightly further

Adds iterator skb_queue_for_each() to run over a list without modifying it. Signed-off-by: Edward Cree --- include/linux/skbuff.h | 16 include/trace/events/net.h | 7 +++ net/core/dev.c | 4 +++- 3 files changed, 26 insertions(+), 1 deletion(-) diff

[RFC PATCH v2 net-next 02/12] sfc: batch up RX delivery

Improves packet rate of 1-byte UDP receives by up to 10%. Signed-off-by: Edward Cree --- drivers/net/ethernet/sfc/efx.c| 12 drivers/net/ethernet/sfc/net_driver.h | 3 +++ drivers/net/ethernet/sfc/rx.c | 7 ++- 3 files changed, 21 insertions(+), 1 deletion

[RFC PATCH v2 net-next 01/12] net: core: trivial netif_receive_skb_list() entry point

Just calls netif_receive_skb() in a loop. Signed-off-by: Edward Cree --- include/linux/netdevice.h | 1 + net/core/dev.c| 20 2 files changed, 21 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 3ec9850c7936..105087369779

[RFC PATCH v2 net-next 00/12] Handle multiple received packets at each stage

r etc. [1] http://vger.kernel.org/netconf2018_files/DavidMiller_netconf2018.pdf [2] http://vger.kernel.org/netconf2018_files/EdwardCree_netconf2018.pdf [3] http://lists.openwall.net/netdev/2016/04/19/89 Edward Cree (12): net: core: trivial netif_receive_skb_list() entry point sfc: batch up RX deli

Re: [PATCH bpf] bpf: reject passing modified ctx to helper functions

work value tracking") > Reported-by: syzbot+3d0b2441dbb717516...@syzkaller.appspotmail.com > Reported-by: syzbot+c8504affd4fdd0c1b...@syzkaller.appspotmail.com > Reported-by: syzbot+e5190cb881d8660fb...@syzkaller.appspotmail.com > Reported-by: syzbot+efae31b384d5badbd...@syzkaller.appspotmail.com > Signed-off-by: Daniel Borkmann > Acked-by: Alexei Starovoitov Acked-by: Edward Cree

Re: [PATCH v2 net-next] sfc: stop the TX queue before pushing new buffers

m> > Tested-by: Jarod Wilson <ja...@redhat.com> > Signed-off-by: Martin Habets <mhab...@solarflare.com> Acked-by: Edward Cree <ec...@solarflare.com>

Re: [PATCH net-next] sfc: stop the TX queue before pushing new buffers

On 23/05/18 10:41, Martin Habets wrote: > efx_enqueue_skb() can push new buffers for the xmit_more functionality. > We must stops the TX queue before this or else the TX queue does not get > restarted and we get a netdev watchdog. > > In the error handling we may now need to unwind more than 1

Re: [PATCH] net: vxge: fix spelling mistake in macro VXGE_HW_ERR_PRIVILAGED_OPEARATION

On 22/05/18 16:36, Colin King wrote: > From: Colin Ian King > > Rename VXGE_HW_ERR_PRIVILAGED_OPEARATION to VXGE_HW_ERR_PRIVILAGED_OPERATION > to fix spelling mistake. > > Signed-off-by: Colin Ian King "Privilaged" doesn't look right either,

Re: [PATCH net-next 08/12] amd-xgbe: Add ethtool show/set channels support

On 22/05/18 14:24, Tom Lendacky wrote: > The amd-xgbe driver is not designed to allocate separate IRQs for Rx and > Tx. In general, there is one IRQ for a channel of which Tx and Rx are > shared. You can have more Tx channels than Rx channels or vice-versa, but > the min() of those numbers will

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

On 03/05/18 05:36, Alexei Starovoitov wrote: > bpfilter.ko consists of bpfilter_kern.c (normal kernel module code) > and user mode helper code that is embedded into bpfilter.ko > > The steps to build bpfilter.ko are the following: > - main.c is compiled by HOSTCC into the bpfilter_umh elf

Re: [RFC PATCH v3 bpf-next 2/5] bpf/verifier: rewrite subprog boundary detection

On 18/04/18 00:48, Alexei Starovoitov wrote: > as I was saying before this is no go. > subprogno is meaningless in the hierarchy of: prog -> func -> bb -> insn > Soon bpf will have libraries and this field would need to become > a pointer back to bb or func structure creating unnecessary circular

Re: [PATCH bpf-next] bpf: relax constraints on formatting for eBPF helper documentation

On 30/04/18 16:59, Quentin Monnet wrote: > The Python script used to parse and extract eBPF helpers documentation > from include/uapi/linux/bpf.h expects a very specific formatting for the > descriptions (single dots represent a space, '>' stands for a tab): > > /* > ... > *.int

Re: [PATCH] ethtool: fix a potential missing-check bug

On 30/04/18 02:31, Wenwen Wang wrote: > In ethtool_get_rxnfc(), the object "info" is firstly copied from > user-space. If the FLOW_RSS flag is set in the member field flow_type of > "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from > user-space because FLOW_RSS is newer and has

[PATCH net 0/2] sfc: more ARFS fixes

A couple more bits of breakage in my recent ARFS and async filters work. Patch #1 in particular fixes a bug that leads to memory trampling and consequent crashes. Edward Cree (2): sfc: Use filter index rather than ID for rps_flow_id table sfc: fix ARFS expiry check on EF10 drivers/net

[PATCH net 1/2] sfc: Use filter index rather than ID for rps_flow_id table

back into an index (which is what the remove call in the expiry path expects, anyway). Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/rx.c | 2 ++ 1 file changed, 2 insertions(+)

[PATCH net 2/2] sfc: fix ARFS expiry check on EF10

Owing to a missing conditional, the result of rps_may_expire_flow() was being ignored and filters were being removed even if we'd decided not to expire them. Fixes: f8d6203780b7 ("sfc: ARFS filter IDs") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/etherne

[PATCH v3 net] sfc: ARFS filter IDs

and lkp-robot). Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 80 +++ drivers/net/ethernet/sfc/efx.c| 143 +++

Re: [PATCH v2 net] sfc: ARFS filter IDs

On 24/04/18 15:14, Edward Cree wrote: > Associate an arbitrary ID with each ARFS filter, allowing to properly query > for expiry. The association is maintained in a hash table, which is > protected by a spinlock. > > v2: fixed uninitialised variable (thanks davem and lkp-ro

[PATCH v2 net] sfc: ARFS filter IDs

ilter operations") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 80 +++ drivers/net/ethernet/sfc/efx.c| 143 ++ drivers/net/ethernet/sfc/efx.h| 19 + drivers/net/ethe

[PATCH net] sfc: ARFS filter IDs

Associate an arbitrary ID with each ARFS filter, allowing to properly query for expiry. The association is maintained in a hash table, which is protected by a spinlock. Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations") Signed-off-by: Edward Cree <ec...@s

Re: [PATCH bpf-next v3 4/9] bpf/verifier: improve register value range tracking with ARSH

On 20/04/18 23:18, Yonghong Song wrote: > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 3c8bb92..01c215d 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -2975,6 +2975,32 @@ static int adjust_scalar_min_max_vals(struct > bpf_verifier_env *env, >

[PATCH v2 net 3/3] sfc: limit ARFS workitems in flight per channel

should not negatively impact performance, because it is only likely to be hit in cases where ARFS will be ineffective anyway. Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/net_driver.h | 25 +++ drivers/net/ethernet/sfc/rx.c

[PATCH v2 net 2/3] sfc: pass the correctly bogus filter_id to rps_may_expire_flow()

("sfc: replace asynchronous filter operations") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 3 +-- drivers/net/ethernet/sfc/farch.c | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/sfc/ef10

[PATCH v2 net 1/3] sfc: insert ARFS filters with replace_equal=true

Necessary to allow redirecting a flow when the application moves. Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v2 net 0/3] sfc: ARFS fixes

also the issue that we come up in the bad configuration that triggers #3 by default, but that too is a problem for another time. Edward Cree (3): sfc: insert ARFS filters with replace_equal=true sfc: pass the correctly bogus filter_id to rps_may_expire_flow() sfc: limit ARFS workitems

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

On 13/04/18 17:14, David Miller wrote: > Is the issue that you learn about the hardware reset asynchronously, > and therefore cannot determine if filter insertion programming > happened afterwards and thus is still in the chip? Yes, pretty much. > You must have a table of all the entries, so that

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

On 13/04/18 16:03, David Miller wrote: > Whilst you may not be able to program the filter into the hardware > synchronously, you should be able to allocate the ID and get all of > the software state setup. That's what we were doing before commit 3af0f34290f6 ("sfc: replace  asynchronous filter

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

On 13/04/18 13:36, Edward Cree wrote: > It turns out this may all be moot anyway: I figured out why I was seeing >  ARFS storms and it wasn't the configuration issue I originally blamed. Hmm, correction, while the fix I mentioned in my previous email is needed,  it doesn't prevent the ARFS

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

It turns out this may all be moot anyway: I figured out why I was seeing  ARFS storms and it wasn't the configuration issue I originally blamed. My current ndo_rx_flow_steer() implementation, efx_filter_rfs(), returns  0 for success, but the caller expects a filter ID to be returned (which  we

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

On 12/04/18 16:11, David Miller wrote: > From: Edward Cree <ec...@solarflare.com> > Date: Thu, 12 Apr 2018 15:02:50 +0100 > >> A misconfigured system (e.g. with all interrupts affinitised to all CPUs) >> may produce a storm of ARFS steering events. With the existing

[PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/net_driver.h | 25 +++ drivers/net/ethernet/sfc/rx.c | 58 ++- 2 files changed, 55 insertions(+), 28 deletions(-) diff --git a/drivers/net/ethernet/sfc/net_driver.h b/d

[PATCH net 1/2] sfc: insert ARFS filters with replace_equal=true

Necessary to allow redirecting a flow when the application moves. Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH net 0/2] sfc: couple of ARFS fixes

in the bad configuration by default, but that too is a problem for another time.) Edward Cree (2): sfc: insert ARFS filters with replace_equal=true sfc: limit ARFS workitems in flight per channel drivers/net/ethernet/sfc/net_driver.h | 25 +++ drivers/net/ethernet/sfc/rx.c

[RFC PATCH v3 bpf-next 5/5] bpf/verifier: per-register parent pointers

-r5 into the callee as args, and r0 out as the return value) they also copy the parent pointer. Signed-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/bpf_verifier.h | 8 +- kernel/bpf/verifier.c| 180 ++- 2 files changed, 45 inse

[RFC PATCH v3 bpf-next 4/5] bpf/verifier: use call graph to efficiently check max stack depth

in calculating the stack depth it implies for the subprog's callees. This is O(number of subprogs). The call graph is populated as part of the check_subprogs() pass. Signed-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/bpf_verifier.h | 3 + kernel/bpf/verifier.c

[RFC PATCH v3 bpf-next 2/5] bpf/verifier: rewrite subprog boundary detection

By storing a subprogno in each insn's aux data, we avoid the need to keep the list of subprog starts sorted or bsearch() it in find_subprog(). Also, get rid of the weird one-based indexing of subprog numbers. Signed-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/bpf_veri

[RFC PATCH v3 bpf-next 1/5] bpf/verifier: store subprog info in struct bpf_subprog_info

Per-subprog info is stored in env->subprog_info, an array of structs, rather than multiple arrays with a common index. Signed-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/bpf_verifier.h | 9 +--- kernel/bpf/verifier.c

[RFC PATCH v3 bpf-next 3/5] bpf/verifier: update selftests

nsns are unreachable. I've changed it so that they are now reachable, which causes static back-edges to be detected (since that, like insn reachability, is now tested before subprog boundaries are determined). Signed-off-by: Edward Cree <ec...@solarflare.com> --- tools/testing/selftest

[RFC PATCH v3 bpf-next 0/5] bpf/verifier: subprog/func_call simplifications

eeded. Changes from v1->v2: * No longer allows non-contiguous subprogs. * No longer allows LD_ABS|IND and pseudo-calls in the same prog. Edward Cree (5): bpf/verifier: store subprog info in struct bpf_subprog_info bpf/verifier: rewrite subprog boundary detection bpf/verifier: update selfte

Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications

On 05/04/18 16:50, Jiong Wang wrote: > On 03/04/2018 02:08, Alexei Starovoitov wrote: >> Combining subprog pass with do_check is going into opposite direction >> of this long term work. Divide and conquer. Combining more things into >> do_check is the opposite of this programming principle. > >

Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications

On 05/04/18 06:28, Alexei Starovoitov wrote: > On Thu, Apr 05, 2018 at 12:58:46AM +0100, Edward Cree wrote: >> On 04/04/18 00:37, Alexei Starovoitov wrote: >>> hmm. that doesn't fail for me and any other bots didn't complain. >>> Are you sure you're running the lat

Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications

On 04/04/18 00:37, Alexei Starovoitov wrote: > hmm. that doesn't fail for me and any other bots didn't complain. > Are you sure you're running the latest kernel and tests? Ah, test_progs isn't actually rebuilding because __NR_bpf is undeclared;  something must be going wrong with header files.

Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications

On 03/04/18 02:08, Alexei Starovoitov wrote: > I like patch 3 and going to play with it. > How did you test it ? Just test_verifier and test_progs (the latter has a failure  "test_bpf_obj_id:FAIL:get-prog-info(fd) err 0 errno 2 i 0 type 1(1) info_len 80(40) jit_enabled 0 jited_prog_len 0

Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications

On 29/03/18 23:44, Edward Cree wrote: > By storing subprog boundaries as a subprogno mark on each insn, rather than > a start (and implicit end) for each subprog, we collect a number of gains: > * More efficient determination of which subprog contains a given insn, and > thus of

[PATCH v2 bpf-next 2/3] bpf/verifier: update selftests

rmined). Signed-off-by: Edward Cree <ec...@solarflare.com> --- tools/testing/selftests/bpf/test_verifier.c | 51 ++--- 1 file changed, 32 insertions(+), 19 deletions(-) diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_ver

[PATCH v2 bpf-next 3/3] bpf/verifier: per-register parent pointers

-r5 into the callee as args, and r0 out as the return value) they also copy the parent pointer. Signed-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/bpf_verifier.h | 8 +- kernel/bpf/verifier.c| 180 ++- 2 files changed, 45 inse

[PATCH v2 bpf-next 1/3] bpf/verifier: validate func_calls by marking at do_check() time

is now O(n) in the number of subprogs, rather than having to walk every insn of every possible call chain. Signed-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/bpf_verifier.h | 24 ++- kernel/bpf/verifier.c| 451 --- 2 files c

[PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications

arking either. Edward Cree (3): bpf/verifier: validate func_calls by marking at do_check() time bpf/verifier: update selftests bpf/verifier: per-register parent pointers include/linux/bpf_verifier.h| 32 +- kernel/bpf/verifier.c

[PATCH net-next 0/6] sfc: rework locking around filter management

context state, since otherwise a similar race is possible around restoring that after an MC reboot. While we're at it, fix a couple of other related bugs. Edward Cree (6): sfc: replace asynchronous filter operations sfc: give ef10 its own rwsem in the filter table instead of filter_lock sfc

[PATCH net-next 1/6] sfc: replace asynchronous filter operations

;rps_flow_id) so that the taking of efx->filter_lock can be moved to efx->type->filter_rfs_expire_one(). Thus, all filter table functions are now called in a sleepable context, allowing them to use sleeping locks in a future patch. Signed-off-by: Edward Cree <ec...@solarflare.com>

[PATCH net-next 3/6] sfc: use a semaphore to lock farch filters too

With this change, the spinlock efx->filter_lock is no longer used and is thus removed. Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/farch.c | 67 +-- drivers/net/ethernet/sfc/net_driver.h | 2 -- 2 files ch

[PATCH net-next 6/6] sfc: fix flow type handling for RSS filters

The FLOW_RSS flag was causing us to insert UDP filters when TCP was wanted. Fixes: 42356d9a137b ("sfc: support RSS spreading of ethtool ntuple filters") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ethtool.c | 11 ++- 1 file changed, 6

[PATCH net-next 4/6] sfc: return a better error if filter insertion collides with MC reboot

ool ntuple request from userland) isn't invalid, it just got unlucky; so return EAGAIN. Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef1

[PATCH net-next 5/6] sfc: protect list of RSS contexts under a mutex

lters") Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 32 ++--- drivers/net/ethernet/sfc/efx.c| 14 ++-- drivers/net/ethernet/sfc/efx.h| 4 +-- drivers/net/ethernet/sfc/e

[PATCH net-next 2/6] sfc: give ef10 its own rwsem in the filter table instead of filter_lock

efx->filter_lock remains in place for use on farch, but EF10 now ignores it. EFX_EF10_FILTER_FLAG_BUSY is no longer needed, hence it is removed. Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 361 ++ dr

[PATCH ethtool] ethtool: don't fall back to grxfhindir when context was specified

In do_grfxh(), if rss_context is non-zero, we must not fall back to do_grxfhindir() if ETHTOOL_GRSSH fails, for that reads the default RSS context and not the one specified. Fixes: f5d55b967e0c ("ethtool: add support for extra RSS contexts and RSS steering filters") Signed-off-by: E

[PATCH net-next 2/2] sfc: support FEC configuration through ethtool

rs|baser (with or without auto bit) means prefer FEC even where auto wouldn't use it, but let FW choose which encoding to use. Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ethtool.c| 32 drivers/net/ethernet/sfc/mcdi_port

[PATCH net-next 0/2] sfc: support FEC configuration

Implements the ethtool get & set fecparam operations. Edward Cree (2): sfc: update MCDI protocol headers sfc: support FEC configuration through ethtool drivers/net/ethernet/sfc/ethtool.c| 32 + drivers/net/ethernet/sfc/mcdi_pcol.h | 2822 + drivers

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 09/03/18 18:58, Alexei Starovoitov wrote: > It's not waiting for the whole thing, because once bpfilter starts it > stays running/sleeping because it's stateful. So, this has been bugging me a bit. If bpfilter takes a signal and crashes, all that state goes away. Does that mean your

[PATCH ethtool 2/3] ethtool: add support for extra RSS contexts and RSS steering filters

RSS contexts can be created on a device with -X ... context new, modified with -X ... context N, and deleted with -X ... context N delete. N-tuple filters can be directed at those contexts with -N ... context N. Signed-off-by: Edward Cree <ec...@solarflare.com> --- ethtool.c

[PATCH ethtool 3/3] ethtool.8: Document RSS context control and RSS filters

Signed-off-by: Edward Cree <ec...@solarflare.com> --- ethtool.8.in | 28 1 file changed, 28 insertions(+) diff --git a/ethtool.8.in b/ethtool.8.in index 690e55e..99ac62f 100644 --- a/ethtool.8.in +++ b/ethtool.8.in @@ -274,6 +274,7 @@ ethtool \- query or c

[PATCH ethtool 1/3] ethtool-copy.h: sync with net-next

This covers kernel changes up to commit 84a1d9c48200, net: ethtool: extend RXNFC API to support RSS spreading of filter matches Signed-off-by: Edward Cree <ec...@solarflare.com> --- ethtool-copy.h | 32 ++-- 1 file changed, 26 insertions(+), 6 deletions(-)

[PATCH ethtool 0/3] RSS ntuple filters

This series adds support for the management of extra RSS contexts and RSS spreading of ntuple/NFC filters introduced in kernel commit 84a1d9c48200 ("net: ethtool: extend RXNFC API to support RSS spreading of filter matches"). Edward Cree (3): ethtool-copy.h: sync with net-next et

[PATCH v2 net-next 2/2] sfc: support RSS spreading of ethtool ntuple filters

Use a linked list to associate user-facing context IDs with FW-facing context IDs (since the latter can change after an MC reset). Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 273 ++ drivers/net/ethernet/sfc

[PATCH v2 net-next 1/2] net: ethtool: extend RXNFC API to support RSS spreading of filter matches

-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/ethtool.h | 5 include/uapi/linux/ethtool.h | 32 +- net/core/ethtool.c | 64 +--- 3 files changed, 80 insertions(+), 21 deletions(-) diff --git a/i

[PATCH v2 net-next 0/2] ntuple filters with RSS

with an equal-weight [0,1] indirection table could be used to target all three containers by setting ring_cookie to 1, 3 and 6 on the respective filters. v2: Initialised ctx in efx_ef10_filter_insert() to avoid (false positive) gcc warning. Edward Cree (2): net: ethtool: extend RXNFC API

Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS

On 07/03/18 15:24, David Miller wrote: > Ok. > > Since nobody is really working on the ethtool --> devlink/netlink conversion, > it really isn't reasonable for me to block useful changes like your's. > > So please resubmit this series and I will apply it. > > Thanks. Ok, thanks.  Should I stick

Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer

On 06/03/18 18:03, Florian Westphal wrote: > I don't know. I suspect we should go for naive algorithm only, > but I would defer such decision to Alexei/Daniel. > > f.e. i don't know if using llvm is a good idea or not, Yeah, I wondered about that too.  I think it's probably not a good idea,  

Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer

On 06/03/18 16:42, Florian Westphal wrote: > I would also add 'highlevel' objects that are themselves translated into > basic operations. Most obvious example > are 'fetch 4 bytes x bytes into transport header'. > > Frontend should not need to bother with ipv4 details, such as ip > options.

Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS

On 01/03/18 18:36, David Miller wrote: > We really should have the ethtool interfaces under deep freeze until we > convert it to netlink or similar. > Second, this is a real hackish way to extend ethtool with new > semantics.  A structure changes layout based upon a flag bit setting > in an

Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS

On Tue, Feb 27, 2018 at 3:47 PM, Jakub Kicinski wrote: > Please, let's stop extending ethtool_rx_flow APIs. I bit my tongue > when Intel was adding their "redirection to VF" based on ethtool ntuples > and look now they're adding the same functionality with flower :| And >

[PATCH net] net: ethtool: don't ignore return from driver get_fecparam method

If ethtool_ops->get_fecparam returns an error, pass that error on to the user, rather than ignoring it. Fixes: 1a5f3da20bd9 ("net: ethtool: add support for forward error correction modes") Signed-off-by: Edward Cree <ec...@solarflare.com> --- net/core/ethtool.c | 5 -

[PATCH net-next 2/2] sfc: support RSS spreading of ethtool ntuple filters

Use a linked list to associate user-facing context IDs with FW-facing context IDs (since the latter can change after an MC reset). Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/ef10.c | 273 ++ drivers/net/ethernet/sfc

<    1   2   3   4   5   6   7   >