* [RFC net-next 00/13] Get rid of switchdev_ops
From: Florian Fainelli @ 2019-02-01 22:06 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Michael Chan, David S. Miller, Derek Chickles,
Satanand Burla, Felix Manlunas, Saeed Mahameed, Leon Romanovsky,
Jiri Pirko, Ido Schimmel, Alexandre Belloni,
Microchip Linux Driver Support, Jakub Kicinski, Ioana Radulescu,
Ioana Ciornei, Greg Kroah-Hartman, Ivan Vecera, Andrew Lunn,
Vivien Didelot, Dirk van der Merwe, Francois H. Theron,
Simon Horman, Quentin Monnet, Daniel Borkmann, Eric Dumazet,
John Hurley, Edwin Peer, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM
Hi all,
This patch series converts SWITCHDEV_PORT_ATTR_{GET,SET} to use a
blocking notifier, similar to how SWITCHDEV_PORT_OBJ_{ADD,DEL} has been
changed recently by Petr.
This was suggested by Ido to help with a particular use case I have
where I want to be able to veto a switchdev bridge attribute from a
driver (multicast_snooping).
Please review since I may not have gotten the driver abstraction right,
especially for mlx5e and nfp since these are *hum* *hum* large drivers.
Florian Fainelli (13):
switchdev: Add SWITCHDEV_PORT_ATTR_SET, SWITCHDEV_PORT_ATTR_GET
rocker: Handle SWITCHDEV_PORT_ATTR_GET/SET
net: dsa: Handle SWITCHDEV_PORT_ATTR_GET/SET
mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_GET/SET
net: mscc: ocelot: Handle SWITCHDEV_PORT_ATTR_GET/SET
staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_GET/SET
bnxt: Handle SWITCHDEV_PORT_ATTR_GET event
liquidio: Handle SWITCHDEV_PORT_ATTR_GET event
mlxsw: switchx2: Handle SWITCHDEV_PORT_ATTR_GET event
net/mlx5e: Handle SWITCHDEV_PORT_ATTR_GET event
nfp: Handle SWITCHDEV_PORT_ATTR_GET event
netdevsim: Handle SWITCHDEV_PORT_ATTR_GET event
net: switchdev: Replace port attr get/set SDO with a notification
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 63 ++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c | 9 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.h | 8 ++
.../net/ethernet/cavium/liquidio/lio_main.c | 53 ++++++++-
.../net/ethernet/cavium/liquidio/lio_vf_rep.c | 48 +++++++-
.../net/ethernet/mellanox/mlx5/core/en_main.c | 4 +-
.../net/ethernet/mellanox/mlx5/core/en_rep.c | 50 ++++++--
.../net/ethernet/mellanox/mlx5/core/en_rep.h | 2 +-
.../net/ethernet/mellanox/mlxsw/spectrum.c | 12 --
.../net/ethernet/mellanox/mlxsw/spectrum.h | 2 -
.../mellanox/mlxsw/spectrum_switchdev.c | 36 +++---
.../net/ethernet/mellanox/mlxsw/switchx2.c | 46 +++++++-
drivers/net/ethernet/mscc/ocelot.c | 30 ++++-
drivers/net/ethernet/netronome/nfp/nfp_main.c | 14 ++-
drivers/net/ethernet/netronome/nfp/nfp_net.h | 3 +
.../ethernet/netronome/nfp/nfp_net_common.c | 19 +++-
.../net/ethernet/netronome/nfp/nfp_net_repr.c | 2 -
drivers/net/ethernet/netronome/nfp/nfp_port.c | 17 ++-
drivers/net/ethernet/netronome/nfp/nfp_port.h | 5 +-
drivers/net/ethernet/rocker/rocker_main.c | 30 ++++-
drivers/net/netdevsim/netdev.c | 46 +++++++-
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 30 ++++-
include/linux/netdevice.h | 3 -
include/net/switchdev.h | 28 ++---
net/dsa/slave.c | 30 ++++-
net/switchdev/switchdev.c | 107 ++++++------------
26 files changed, 503 insertions(+), 194 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH bpf-next v6 2/5] bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
From: Peter Oskolkov @ 2019-02-01 22:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Peter Oskolkov, Alexei Starovoitov, Daniel Borkmann, netdev,
David Ahern, Willem de Bruijn
In-Reply-To: <20190201210640.yjnb4jriekec3mcs@ast-mbp>
On Fri, Feb 1, 2019 at 1:06 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Feb 01, 2019 at 09:22:26AM -0800, Peter Oskolkov wrote:
> > This patch implements BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
> > BPF helper. It enables BPF programs (specifically, BPF_PROG_TYPE_LWT_IN
> > and BPF_PROG_TYPE_LWT_XMIT prog types) to add IP encapsulation headers
> > to packets (e.g. IP/GRE, GUE, IPIP).
> >
> > This is useful when thousands of different short-lived flows should be
> > encapped, each with different and dynamically determined destination.
> > Although lwtunnels can be used in some of these scenarios, the ability
> > to dynamically generate encap headers adds more flexibility, e.g.
> > when routing depends on the state of the host (reflected in global bpf
> > maps).
> >
> > Note: a follow-up patch with deal with GSO-enabled packets, which
> > are currently rejected at encapping attempt.
> >
> > Signed-off-by: Peter Oskolkov <posk@google.com>
> ...
> > +int bpf_lwt_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len, bool ingress)
> > +{
> > + struct iphdr *iph;
> > + bool ipv4;
> > + int err;
> > +
> > + if (unlikely(len < sizeof(struct iphdr) || len > LWT_BPF_MAX_HEADROOM))
> > + return -EINVAL;
> > +
> > + /* GSO-enabled packets cannot be encapped at the moment. */
> > + if (unlikely(skb_is_gso(skb)))
> > + return -EINVAL;
>
> I don't understand why that's 'unlikely'.
> Both tx and rx are very likely to have gso skbs.
> Are you saying this feature will require user to disable gro/gso on a device?
> imo gso has to be supported from the start.
OK, I'll work on v7 with GSO support... :)
>
^ permalink raw reply
* [PATCH bpf-next 0/2] nfp: bpf: shifts support cleanups
From: Jiong Wang @ 2019-02-01 22:39 UTC (permalink / raw)
To: ast, daniel; +Cc: jakub.kicinski, netdev, oss-drivers, Jiong Wang
NFP JIT back-end is missing several ALU32 logic shifts support.
Also, shifts with shift amount be zero are not handled properly.
This set cleans up these issues.
Jiong Wang (2):
nfp: bpf: correct the behavior for shifts by zero
nfp: bpf: complete ALU32 shift supports
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 92 +++++++++++++++++++++++++---
1 file changed, 82 insertions(+), 10 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH bpf-next 1/2] nfp: bpf: correct the behavior for shifts by zero
From: Jiong Wang @ 2019-02-01 22:39 UTC (permalink / raw)
To: ast, daniel; +Cc: jakub.kicinski, netdev, oss-drivers, Jiong Wang
In-Reply-To: <1549060769-20920-1-git-send-email-jiong.wang@netronome.com>
Shifts by zero do nothing, and should be treated as nops.
Even though compiler is not supposed to generate such instructions and
manual written assembly is unlikely to have them, but they are legal
instructions and have defined behavior.
This patch correct existing shifts code-gen to make sure they do nothing
when shift amount is zero except when the instruction is ALU32 for which
high bits need to be cleared.
For shift amount bigger than type size, already, NFP JIT back-end errors
out for immediate shift and only low 5 bits will be taken into account for
indirect shift which is the same as x86.
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
---
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 30 ++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/bpf/jit.c b/drivers/net/ethernet/netronome/nfp/bpf/jit.c
index aa3a209..093b8ff 100644
--- a/drivers/net/ethernet/netronome/nfp/bpf/jit.c
+++ b/drivers/net/ethernet/netronome/nfp/bpf/jit.c
@@ -1967,6 +1967,9 @@ static int neg_reg64(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
*/
static int __shl_imm64(struct nfp_prog *nfp_prog, u8 dst, u8 shift_amt)
{
+ if (!shift_amt)
+ return 0;
+
if (shift_amt < 32) {
emit_shf(nfp_prog, reg_both(dst + 1), reg_a(dst + 1),
SHF_OP_NONE, reg_b(dst), SHF_SC_R_DSHF,
@@ -2079,6 +2082,9 @@ static int shl_reg64(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
*/
static int __shr_imm64(struct nfp_prog *nfp_prog, u8 dst, u8 shift_amt)
{
+ if (!shift_amt)
+ return 0;
+
if (shift_amt < 32) {
emit_shf(nfp_prog, reg_both(dst), reg_a(dst + 1), SHF_OP_NONE,
reg_b(dst), SHF_SC_R_DSHF, shift_amt);
@@ -2180,6 +2186,9 @@ static int shr_reg64(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
*/
static int __ashr_imm64(struct nfp_prog *nfp_prog, u8 dst, u8 shift_amt)
{
+ if (!shift_amt)
+ return 0;
+
if (shift_amt < 32) {
emit_shf(nfp_prog, reg_both(dst), reg_a(dst + 1), SHF_OP_NONE,
reg_b(dst), SHF_SC_R_DSHF, shift_amt);
@@ -2388,10 +2397,13 @@ static int neg_reg(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
static int __ashr_imm(struct nfp_prog *nfp_prog, u8 dst, u8 shift_amt)
{
- /* Set signedness bit (MSB of result). */
- emit_alu(nfp_prog, reg_none(), reg_a(dst), ALU_OP_OR, reg_imm(0));
- emit_shf(nfp_prog, reg_both(dst), reg_none(), SHF_OP_ASHR, reg_b(dst),
- SHF_SC_R_SHF, shift_amt);
+ if (shift_amt) {
+ /* Set signedness bit (MSB of result). */
+ emit_alu(nfp_prog, reg_none(), reg_a(dst), ALU_OP_OR,
+ reg_imm(0));
+ emit_shf(nfp_prog, reg_both(dst), reg_none(), SHF_OP_ASHR,
+ reg_b(dst), SHF_SC_R_SHF, shift_amt);
+ }
wrp_immed(nfp_prog, reg_both(dst + 1), 0);
return 0;
@@ -2433,12 +2445,10 @@ static int shl_imm(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
{
const struct bpf_insn *insn = &meta->insn;
- if (!insn->imm)
- return 1; /* TODO: zero shift means indirect */
-
- emit_shf(nfp_prog, reg_both(insn->dst_reg * 2),
- reg_none(), SHF_OP_NONE, reg_b(insn->dst_reg * 2),
- SHF_SC_L_SHF, insn->imm);
+ if (insn->imm)
+ emit_shf(nfp_prog, reg_both(insn->dst_reg * 2),
+ reg_none(), SHF_OP_NONE, reg_b(insn->dst_reg * 2),
+ SHF_SC_L_SHF, insn->imm);
wrp_immed(nfp_prog, reg_both(insn->dst_reg * 2 + 1), 0);
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next 2/2] nfp: bpf: complete ALU32 logic shift supports
From: Jiong Wang @ 2019-02-01 22:39 UTC (permalink / raw)
To: ast, daniel; +Cc: jakub.kicinski, netdev, oss-drivers, Jiong Wang
In-Reply-To: <1549060769-20920-1-git-send-email-jiong.wang@netronome.com>
The following ALU32 logic shift supports are missing:
BPF_ALU | BPF_LSH | BPF_X
BPF_ALU | BPF_RSH | BPF_X
BPF_ALU | BPF_RSH | BPF_K
For BPF_RSH | BPF_K, it could be implemented using NFP direct shift
instruction. For the other BPF_X shifts, NFP indirect shifts sequences need
to be used.
Separate code-gen hook is assigned to each instruction to make the
implementation clear.
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
---
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 72 ++++++++++++++++++++++++++--
1 file changed, 67 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/bpf/jit.c b/drivers/net/ethernet/netronome/nfp/bpf/jit.c
index 093b8ff..4d9d380 100644
--- a/drivers/net/ethernet/netronome/nfp/bpf/jit.c
+++ b/drivers/net/ethernet/netronome/nfp/bpf/jit.c
@@ -2441,16 +2441,75 @@ static int ashr_imm(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
return __ashr_imm(nfp_prog, dst, insn->imm);
}
+static int __shr_imm(struct nfp_prog *nfp_prog, u8 dst, u8 shift_amt)
+{
+ if (shift_amt)
+ emit_shf(nfp_prog, reg_both(dst), reg_none(), SHF_OP_NONE,
+ reg_b(dst), SHF_SC_R_SHF, shift_amt);
+ wrp_immed(nfp_prog, reg_both(dst + 1), 0);
+ return 0;
+}
+
+static int shr_imm(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
+{
+ const struct bpf_insn *insn = &meta->insn;
+ u8 dst = insn->dst_reg * 2;
+
+ return __shr_imm(nfp_prog, dst, insn->imm);
+}
+
+static int shr_reg(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
+{
+ const struct bpf_insn *insn = &meta->insn;
+ u64 umin, umax;
+ u8 dst, src;
+
+ dst = insn->dst_reg * 2;
+ umin = meta->umin_src;
+ umax = meta->umax_src;
+ if (umin == umax)
+ return __shr_imm(nfp_prog, dst, umin);
+
+ src = insn->src_reg * 2;
+ emit_alu(nfp_prog, reg_none(), reg_a(src), ALU_OP_OR, reg_imm(0));
+ emit_shf_indir(nfp_prog, reg_both(dst), reg_none(), SHF_OP_NONE,
+ reg_b(dst), SHF_SC_R_SHF);
+ wrp_immed(nfp_prog, reg_both(dst + 1), 0);
+ return 0;
+}
+
+static int __shl_imm(struct nfp_prog *nfp_prog, u8 dst, u8 shift_amt)
+{
+ if (shift_amt)
+ emit_shf(nfp_prog, reg_both(dst), reg_none(), SHF_OP_NONE,
+ reg_b(dst), SHF_SC_L_SHF, shift_amt);
+ wrp_immed(nfp_prog, reg_both(dst + 1), 0);
+ return 0;
+}
+
static int shl_imm(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
{
const struct bpf_insn *insn = &meta->insn;
+ u8 dst = insn->dst_reg * 2;
- if (insn->imm)
- emit_shf(nfp_prog, reg_both(insn->dst_reg * 2),
- reg_none(), SHF_OP_NONE, reg_b(insn->dst_reg * 2),
- SHF_SC_L_SHF, insn->imm);
- wrp_immed(nfp_prog, reg_both(insn->dst_reg * 2 + 1), 0);
+ return __shl_imm(nfp_prog, dst, insn->imm);
+}
+static int shl_reg(struct nfp_prog *nfp_prog, struct nfp_insn_meta *meta)
+{
+ const struct bpf_insn *insn = &meta->insn;
+ u64 umin, umax;
+ u8 dst, src;
+
+ dst = insn->dst_reg * 2;
+ umin = meta->umin_src;
+ umax = meta->umax_src;
+ if (umin == umax)
+ return __shl_imm(nfp_prog, dst, umin);
+
+ src = insn->src_reg * 2;
+ shl_reg64_lt32_low(nfp_prog, dst, src);
+ wrp_immed(nfp_prog, reg_both(dst + 1), 0);
return 0;
}
@@ -3360,7 +3419,10 @@ static const instr_cb_t instr_cb[256] = {
[BPF_ALU | BPF_DIV | BPF_X] = div_reg,
[BPF_ALU | BPF_DIV | BPF_K] = div_imm,
[BPF_ALU | BPF_NEG] = neg_reg,
+ [BPF_ALU | BPF_LSH | BPF_X] = shl_reg,
[BPF_ALU | BPF_LSH | BPF_K] = shl_imm,
+ [BPF_ALU | BPF_RSH | BPF_X] = shr_reg,
+ [BPF_ALU | BPF_RSH | BPF_K] = shr_imm,
[BPF_ALU | BPF_ARSH | BPF_X] = ashr_reg,
[BPF_ALU | BPF_ARSH | BPF_K] = ashr_imm,
[BPF_ALU | BPF_END | BPF_X] = end_reg32,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 net-next 2/5] exthdrs: Registration of TLV handlers and parameters
From: David Miller @ 2019-02-01 22:40 UTC (permalink / raw)
To: tom; +Cc: netdev, tom
In-Reply-To: <1548699775-3015-3-git-send-email-tom@quantonium.net>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 28 Jan 2019 10:22:52 -0800
> + tpt = vmalloc(tlv_param_table_size(old->count - 1));
> + if (!tpt)
> + return -ENOMEM;
...
> + tsize = tlv_param_table_size(ARRAY_SIZE(tlv_init_params) + 1);
> +
> + tpt = vmalloc(tsize);
> + if (!tpt)
> + return -ENOMEM;
Most of the time this is going to be well within range for a quick, more
efficient, linearly mapped kmalloc allocation.
So please use kvzalloc() or similar for this table.
^ permalink raw reply
* Re: [PATCH net] enic: fix checksum validation for IPv6
From: David Miller @ 2019-02-01 22:44 UTC (permalink / raw)
To: gvaradar; +Cc: netdev, benve
In-Reply-To: <20190130145900.2614-1-gvaradar@cisco.com>
From: Govindarajulu Varadarajan <gvaradar@cisco.com>
Date: Wed, 30 Jan 2019 06:59:00 -0800
> In case of IPv6 pkts, ipv4_csum_ok is 0. Because of this, driver does
> not set skb->ip_summed. So IPv6 rx checksum is not offloaded.
>
> Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next v6 0/8] xdp: Avoid unloading xdp prog not attached by sample
From: Daniel Borkmann @ 2019-02-01 22:46 UTC (permalink / raw)
To: Maciej Fijalkowski, ast; +Cc: netdev, jakub.kicinski, brouer, john.fastabend
In-Reply-To: <20190201214230.1441-1-maciej.fijalkowski@intel.com>
On 02/01/2019 10:42 PM, Maciej Fijalkowski wrote:
> Hi!
> This patchset tries to address the situation where:
> * user loads a particular xdp sample application that does stats polling
> * user loads another sample application on the same interface
> * then, user sends SIGINT/SIGTERM to the app that was attached as a first one
> * second application ends up with an unloaded xdp program
>
> 1st patch contains a helper libbpf function for getting the map fd by a
> given map name.
> In patch 2 Jesper removes the read_trace_pipe usage from xdp_redirect_cpu which
> was a blocker for converting this sample to libbpf usage.
> 3rd patch updates a bunch of xdp samples to make the use of libbpf.
> Patch 4 adjusts RLIMIT_MEMLOCK for two samples touched in this patchset.
> In patch 5 extack messages are added for cases where dev_change_xdp_fd returns
> with an error so user has an idea what was the reason for not attaching the
> xdp program onto interface.
> Patch 6 makes the samples behavior similar to what iproute2 does when loading
> xdp prog - the "force" flag is introduced.
> Patch 7 introduces the libbpf function that will query the driver from
> userspace about the currently attached xdp prog id.
>
> Use it in samples that do polling by checking the prog id in signal handler
> and comparing it with previously stored one which is the scope of patch 8.
>
> Thanks!
>
> v1->v2:
> * add a libbpf helper for getting a prog via relative index
> * include xdp_redirect_cpu into conversion
>
> v2->v3: mostly addressing Daniel's/Jesper's comments
> * get rid of the helper from v1->v2
> * feed the xdp_redirect_cpu with program name instead of number
>
> v3->v4:
> * fix help message in xdp_sample_pkts
>
> v4->v5:
> * in get_link_xdp_fd, assign prog_id only when libbpf_nl_get_link returned
> with 0
> * add extack messages in dev_change_xdp_fd
> * check the return value of bpf_get_link_xdp_id when exiting from sample progs
>
> v5->v6:
> * rebase
>
> Jesper Dangaard Brouer (1):
> samples/bpf: xdp_redirect_cpu have not need for read_trace_pipe
>
> Maciej Fijalkowski (7):
> libbpf: Add a helper for retrieving a map fd for a given name
> samples/bpf: Convert XDP samples to libbpf usage
> samples/bpf: Extend RLIMIT_MEMLOCK for xdp_{sample_pkts, router_ipv4}
> xdp: Provide extack messages when prog attachment failed
> samples/bpf: Add a "force" flag to XDP samples
> libbpf: Add a support for getting xdp prog id on ifindex
> samples/bpf: Check the prog id before exiting
>
> net/core/dev.c | 12 ++-
> samples/bpf/Makefile | 8 +-
> samples/bpf/xdp1_user.c | 34 ++++++-
> samples/bpf/xdp_adjust_tail_user.c | 38 +++++--
> samples/bpf/xdp_redirect_cpu_user.c | 196 +++++++++++++++++++++++++-----------
> samples/bpf/xdp_redirect_map_user.c | 106 +++++++++++++++----
> samples/bpf/xdp_redirect_user.c | 103 ++++++++++++++++---
> samples/bpf/xdp_router_ipv4_user.c | 179 +++++++++++++++++++++++---------
> samples/bpf/xdp_rxq_info_user.c | 41 ++++++--
> samples/bpf/xdp_sample_pkts_user.c | 81 ++++++++++++---
> samples/bpf/xdp_tx_iptunnel_user.c | 71 ++++++++++---
> samples/bpf/xdpsock_user.c | 30 +++++-
> tools/lib/bpf/libbpf.c | 6 ++
> tools/lib/bpf/libbpf.h | 4 +
> tools/lib/bpf/libbpf.map | 2 +
> tools/lib/bpf/netlink.c | 85 ++++++++++++++++
> 16 files changed, 796 insertions(+), 200 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net 0/9] net/smc: fixes 2019-01-30
From: David Miller @ 2019-02-01 22:48 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20190130175108.103221-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Wed, 30 Jan 2019 18:50:59 +0100
> here are some fixes in different areas of the smc code for the net
> tree.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] dccp: fool proof ccid_hc_[rt]x_parse_options()
From: David Miller @ 2019-02-01 22:49 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, syzkaller, gerrit
In-Reply-To: <20190130193941.111767-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 30 Jan 2019 11:39:41 -0800
> Similarly to commit 276bdb82dedb ("dccp: check ccid before dereferencing")
> it is wise to test for a NULL ccid.
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH bpf-next v3 1/3] tools/bpf: move libbpf pr_* debug print functions to headers
From: Alexei Starovoitov @ 2019-02-01 22:52 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, Magnus Karlsson, netdev,
Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20190201220616.1802957-1-yhs@fb.com>
On Fri, Feb 01, 2019 at 02:06:16PM -0800, Yonghong Song wrote:
> A global function libbpf_debug_print, which is invisible
> outside the shared library, is defined to print based
> on levels. The pr_warning, pr_info and pr_debug
> macros are moved into the newly created header
> common.h. So any .c file including common.h can
> use these macros directly.
s/common.h/util.h/ ?
I understand that util.h is libbpf's internal header, but still
I'm worried that such file name is too generic and if users
get their header paths wrong they may pick it by accident.
May be call it libbpf_util.h instead?
>
> Currently btf__new and btf_ext__new API has an argument getting
> __pr_debug function pointer into btf.c so the debugging information
> can be printed there. This patch removed this parameter
> from btf__new and btf_ext__new and directly using pr_debug in btf.c.
>
> Another global function libbpf_dprint_level_available, also
> invisible outside the shared library, can test
> whether a particular level debug printing is
> available or not. It is used in btf.c to
> test whether DEBUG level debug printing is availabl or not,
> based on which the log buffer will be allocated when loading
> btf to the kernel.
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
...
> diff --git a/tools/lib/bpf/util.h b/tools/lib/bpf/util.h
> new file mode 100644
> index 000000000000..3ae80f486875
> --- /dev/null
> +++ b/tools/lib/bpf/util.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
> +/* Copyright (c) 2019 Facebook */
> +
> +#ifndef __LIBBPF_COMMON_H
> +#define __LIBBPF_COMMON_H
s/COMMON/new name/
> +
> +#include <stdbool.h>
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +extern void libbpf_debug_print(enum libbpf_print_level level,
> + const char *format, ...)
> + __attribute__((format(printf, 2, 3)));
May be shorten the name to libbpf_print ?
Such name will match enum libbpf_print_level and libbpf_set_print.
> +
> +extern bool libbpf_dprint_level_available(enum libbpf_print_level level);
> +
> +#define __pr(level, fmt, ...) \
> +do { \
> + libbpf_debug_print(level, "libbpf: " fmt, ##__VA_ARGS__); \
> +} while (0)
> +
> +#define pr_warning(fmt, ...) __pr(LIBBPF_WARN, fmt, ##__VA_ARGS__)
> +#define pr_info(fmt, ...) __pr(LIBBPF_INFO, fmt, ##__VA_ARGS__)
> +#define pr_debug(fmt, ...) __pr(LIBBPF_DEBUG, fmt, ##__VA_ARGS__)
> +
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> +#endif
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: add optional memory accounting for maps
From: Alexei Starovoitov @ 2019-02-01 22:58 UTC (permalink / raw)
To: Martynas; +Cc: netdev, ast, daniel, Y Song
In-Reply-To: <1549019025.1438919.1648518112.6139DD49@webmail.messagingengine.com>
On Fri, Feb 01, 2019 at 01:03:45PM +0200, Martynas wrote:
>
> > There are nokmem and nosocket memcg boot options.
> > We can add one more to turn off accounting of bpf map memory.
> >
>
> Considering the suggested boot option, I'm OK with enabling it by default. Do you want me to add the option as part of this PR?
yes. please.
^ permalink raw reply
* Re: [PATCH bpf-next v5 7/8] libbpf: Add a support for getting xdp prog id on ifindex
From: Daniel Borkmann @ 2019-02-01 23:00 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Maciej Fijalkowski, ast, netdev, brouer, john.fastabend
In-Reply-To: <20190201134746.59386942@cakuba.hsd1.ca.comcast.net>
On 02/01/2019 10:47 PM, Jakub Kicinski wrote:
> On Fri, 1 Feb 2019 22:43:39 +0100, Daniel Borkmann wrote:
>> On 02/01/2019 01:19 AM, Maciej Fijalkowski wrote:
>>> Since we have a dedicated netlink attributes for xdp setup on a
>>> particular interface, it is now possible to retrieve the program id that
>>> is currently attached to the interface. The use case is targeted for
>>> sample xdp programs, which will store the program id just after loading
>>> bpf program onto iface. On shutdown, the sample will make sure that it
>>> can unload the program by querying again the iface and verifying that
>>> both program id's matches.
>>>
>>> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>>> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> [...]
>>> +int bpf_get_link_xdp_id(int ifindex, __u32 *prog_id, __u32 flags)
>>> +{
>>> + struct xdp_id_md xdp_id = {};
>>> + int sock, ret;
>>> + __u32 nl_pid;
>>> + __u32 mask;
>>> +
>>> + if (flags & ~XDP_FLAGS_MASK)
>>> + return -EINVAL;
>>> +
>>> + /* Check whether the single {HW,DRV,SKB} mode is set */
>>> + flags &= (XDP_FLAGS_SKB_MODE | XDP_FLAGS_DRV_MODE | XDP_FLAGS_HW_MODE);
>>> + mask = flags - 1;
>>> + if (flags && flags & mask)
>>> + return -EINVAL;
>>> +
>>> + sock = libbpf_netlink_open(&nl_pid);
>>> + if (sock < 0)
>>> + return sock;
>>> +
>>> + xdp_id.ifindex = ifindex;
>>> + xdp_id.flags = flags;
>>> +
>>> + ret = libbpf_nl_get_link(sock, nl_pid, get_xdp_id, &xdp_id);
>>> + if (!ret)
>>> + *prog_id = xdp_id.id;
>>> +
>>> + close(sock);
>>> + return ret;
>>> +}
>>
>> Btw, is anyone going to follow-up on XDP_ATTACHED_MULTI support as well
>> later on?
>
> I haven't tested to be honest, but I think Maciek got that right -
> get_xdp_id_attr() should return IFLA_XDP_PROG_ID or a mode-specific
> attr based on flags. And there is a check that only flag is set.
>
> Or do you mean retrieving all program ids with one dump?
Yeah was thinking about the latter, but agree it's fine and probably
cleaner this way here.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] net: tls: TLS 1.3 support
From: David Miller @ 2019-02-01 23:01 UTC (permalink / raw)
To: davejwatson; +Cc: netdev, vakul.garg, borisp, aviadye, john.fastabend, daniel
In-Reply-To: <20190130215757.f4hagzixalffnzte@davejwatson-mba.local>
From: Dave Watson <davejwatson@fb.com>
Date: Wed, 30 Jan 2019 21:57:58 +0000
> This patchset adds 256bit keys and TLS1.3 support to the kernel TLS
> socket.
>
> TLS 1.3 is requested by passing TLS_1_3_VERSION in the setsockopt
> call, which changes the framing as required for TLS1.3.
>
> 256bit keys are requested by passing TLS_CIPHER_AES_GCM_256 in the
> sockopt. This is a fairly straightforward passthrough to the crypto
> framework.
>
> 256bit keys work with both TLS 1.2 and TLS 1.3
>
> TLS 1.3 requires a different AAD layout, necessitating some minor
> refactoring. It also moves the message type byte to the encrypted
> portion of the message, instead of the cleartext header as it was in
> TLS1.2. This requires moving the control message handling to after
> decryption, but is otherwise similar.
>
> V1 -> V2
>
> The first two patches were dropped, and sent separately, one as a
> bugfix to the net tree.
Series applied, thanks Dave.
I'll push this out to net-next once my build testing completes.
Thanks again.
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/3] tools/bpf: move libbpf pr_* debug print functions to headers
From: Arnaldo Carvalho de Melo @ 2019-02-01 23:10 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, Magnus Karlsson, netdev,
Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20190201174731.695515-1-yhs@fb.com>
Em Fri, Feb 01, 2019 at 09:47:31AM -0800, Yonghong Song escreveu:
> @@ -698,13 +695,13 @@ struct btf_ext *btf_ext__new(__u8 *data, __u32 size, btf_print_fn_t err_log)
> if (!btf_ext)
> return ERR_PTR(-ENOMEM);
>
> - err = btf_ext_copy_func_info(btf_ext, data, size, err_log);
> + err = btf_ext_copy_func_info(btf_ext, data, size);
> if (err) {
> btf_ext__free(btf_ext);
One thing I noticed whas that the class + __ + method is not being
consistently followed, will this be dealt with in a followup patch, i.e.
to make this consistently use the format used in the
btf_ext__free(btf_ext) case?
> return ERR_PTR(err);
> }
>
> - err = btf_ext_copy_line_info(btf_ext, data, size, err_log);
> + err = btf_ext_copy_line_info(btf_ext, data, size);
> if (err) {
> btf_ext__free(btf_ext);
> return ERR_PTR(err);
- Arnaldo
^ permalink raw reply
* Re: Co-existing XDP generic and native mode? (Re: [PATCH bpf-next v5 5/8] xdp: Provide extack messages when prog attachment failed)
From: Daniel Borkmann @ 2019-02-01 23:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jesper Dangaard Brouer, ast, David Miller, Maciej Fijalkowski,
netdev, john.fastabend, David Ahern, Saeed Mahameed
In-Reply-To: <20190201134403.44131386@cakuba.hsd1.ca.comcast.net>
On 02/01/2019 10:44 PM, Jakub Kicinski wrote:
[...]
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8e276e0192a1..ce4880e5e95d 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7976,11 +7976,13 @@ int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
> enum bpf_netdev_command query;
> struct bpf_prog *prog = NULL;
> bpf_op_t bpf_op, bpf_chk;
> + bool offload;
> int err;
>
> ASSERT_RTNL();
>
> - query = flags & XDP_FLAGS_HW_MODE ? XDP_QUERY_PROG_HW : XDP_QUERY_PROG;
> + offload = flags & XDP_FLAGS_HW_MODE;
> + query = offload ? XDP_QUERY_PROG_HW : XDP_QUERY_PROG;
>
> bpf_op = bpf_chk = ops->ndo_bpf;
> if (!bpf_op && (flags & (XDP_FLAGS_DRV_MODE | XDP_FLAGS_HW_MODE)))
> @@ -7991,8 +7993,7 @@ int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
> bpf_chk = generic_xdp_install;
>
> if (fd >= 0) {
> - if (__dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG) ||
> - __dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG_HW))
> + if (!offload && __dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG))
> return -EEXIST;
> if ((flags & XDP_FLAGS_UPDATE_IF_NOEXIST) &&
> __dev_xdp_query(dev, bpf_op, query))
> @@ -8003,8 +8004,7 @@ int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
> if (IS_ERR(prog))
> return PTR_ERR(prog);
>
> - if (!(flags & XDP_FLAGS_HW_MODE) &&
> - bpf_prog_is_dev_bound(prog->aux)) {
> + if (!offload && bpf_prog_is_dev_bound(prog->aux)) {
> NL_SET_ERR_MSG(extack, "using device-bound program without HW_MODE flag is not supported");
> bpf_prog_put(prog);
> return -EINVAL;
>
> Do you think we shouldn't do it?
Yeah that looks good to me, lets do it. At least this would allow for
prototyping in combination with HW mode till full support of a feature
has landed properly in native mode.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 0/9] Add ENETC PTP clock driver
From: David Miller @ 2019-02-01 23:17 UTC (permalink / raw)
To: yangbo.lu; +Cc: netdev, devicetree, richardcochran, robh+dt, claudiu.manoil
In-Reply-To: <20190131023310.9563-1-yangbo.lu@nxp.com>
From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Thu, 31 Jan 2019 10:33:01 +0800
> There is same QorIQ 1588 timer IP block on the new ENETC Ethernet
> controller with eTSEC/DPAA Ethernet controllers. However it's
> different endianness (little-endian) and using PCI driver.
>
> To support ENETC PTP driver, ptp_qoriq driver needed to be
> reworked to make functions global for reusing, to add little-
> endian support, to add ENETC memory map support, and to add
> ENETC dependency for ptp_qoriq driver.
>
> In addition, although ENETC PTP driver is a PCI driver, the dts
> node still could be used. Currently the ls1028a dtsi which is
> the only platform by now using ENETC is not complete, so there
> is still dependency for ENETC PTP node upstreaming. This will
> be done in the near future. The hardware timestamping support
> for ENETC is done but needs to be reworked with new method in
> internal git tree, and will be sent out soon.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] stable-kernel-rules.rst: add link to networking patch queue
From: Jonathan Corbet @ 2019-02-01 23:12 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Sasha Levin, stable, linux-doc, linux-kernel, netdev
In-Reply-To: <20190122184632.GA32510@kroah.com>
On Tue, 22 Jan 2019 19:46:32 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> The networking maintainer keeps a public list of the patches being
> queued up for the next round of stable releases. Be sure to check there
> before asking for a patch to be applied so that you do not waste
> people's time.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: David S. Miller <davem@davemloft.net>
> ---
>
> Jon, I can take this through one of my trees if you don't want to, which
> ever is easier for you.
I'm back from my wanderings finally and have just applied it.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/3] tools/bpf: move libbpf pr_* debug print functions to headers
From: Yonghong Song @ 2019-02-01 23:20 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Arnaldo Carvalho de Melo, Magnus Karlsson, netdev@vger.kernel.org,
Alexei Starovoitov, Daniel Borkmann, Kernel Team
In-Reply-To: <20190201231007.GB5593@kernel.org>
On 2/1/19 3:10 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Feb 01, 2019 at 09:47:31AM -0800, Yonghong Song escreveu:
>> @@ -698,13 +695,13 @@ struct btf_ext *btf_ext__new(__u8 *data, __u32 size, btf_print_fn_t err_log)
>> if (!btf_ext)
>> return ERR_PTR(-ENOMEM);
>>
>> - err = btf_ext_copy_func_info(btf_ext, data, size, err_log);
>> + err = btf_ext_copy_func_info(btf_ext, data, size);
>> if (err) {
>> btf_ext__free(btf_ext);
>
> One thing I noticed whas that the class + __ + method is not being
> consistently followed, will this be dealt with in a followup patch, i.e.
> to make this consistently use the format used in the
> btf_ext__free(btf_ext) case?
Currently, the API functions have both +_+ and +__+ method names.
The +_+ is for APIs having a close one-to-one mapping
to system calls. The +__+ is for APIs a little bit high level.
Did you find any particular method whose format is not quite right?
>
>> return ERR_PTR(err);
>> }
>>
>> - err = btf_ext_copy_line_info(btf_ext, data, size, err_log);
>> + err = btf_ext_copy_line_info(btf_ext, data, size);
>> if (err) {
>> btf_ext__free(btf_ext);
>> return ERR_PTR(err);
>
> - Arnaldo
>
^ permalink raw reply
* Re: [PATCH net-next] nfp: use struct_size() in kzalloc()
From: David Miller @ 2019-02-01 23:13 UTC (permalink / raw)
To: gustavo; +Cc: jakub.kicinski, oss-drivers, netdev, linux-kernel
In-Reply-To: <20190131003859.GA28539@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 30 Jan 2019 18:38:59 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: sched: use struct_size() in kvzalloc()
From: David Miller @ 2019-02-01 23:12 UTC (permalink / raw)
To: gustavo; +Cc: vishal, netdev, linux-kernel
In-Reply-To: <20190131002314.GA25771@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 30 Jan 2019 18:23:14 -0600
> One of the more common cases of allocation size calculations is
> finding the size of a structure that has a zero-sized array at
> the end, along with memory for some number of elements for that
> array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/9] Add ENETC PTP clock driver
From: David Miller @ 2019-02-01 23:23 UTC (permalink / raw)
To: yangbo.lu; +Cc: netdev, devicetree, richardcochran, robh+dt, claudiu.manoil
In-Reply-To: <20190201.151702.1371937989366446994.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 01 Feb 2019 15:17:02 -0800 (PST)
> From: Yangbo Lu <yangbo.lu@nxp.com>
> Date: Thu, 31 Jan 2019 10:33:01 +0800
>
>> There is same QorIQ 1588 timer IP block on the new ENETC Ethernet
>> controller with eTSEC/DPAA Ethernet controllers. However it's
>> different endianness (little-endian) and using PCI driver.
>>
>> To support ENETC PTP driver, ptp_qoriq driver needed to be
>> reworked to make functions global for reusing, to add little-
>> endian support, to add ENETC memory map support, and to add
>> ENETC dependency for ptp_qoriq driver.
>>
>> In addition, although ENETC PTP driver is a PCI driver, the dts
>> node still could be used. Currently the ls1028a dtsi which is
>> the only platform by now using ENETC is not complete, so there
>> is still dependency for ENETC PTP node upstreaming. This will
>> be done in the near future. The hardware timestamping support
>> for ENETC is done but needs to be reworked with new method in
>> internal git tree, and will be sent out soon.
>
> Series applied to net-next, thanks.
Actually, I had to revert, this breaks the build:
drivers/net/ethernet/freescale/gianfar_ethtool.c: In function ‘gfar_get_ts_info’:
drivers/net/ethernet/freescale/gianfar_ethtool.c:1513:24: error: dereferencing pointer to incomplete type ‘struct qoriq_ptp’
info->phc_index = ptp->phc_index;
^~
^ permalink raw reply
* Re: [PATCH net-next] ipv4: fib: use struct_size() in kzalloc()
From: David Miller @ 2019-02-01 23:13 UTC (permalink / raw)
To: gustavo; +Cc: kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <20190131005148.GA31194@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 30 Jan 2019 18:51:48 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: smt: use struct_size() in kvzalloc()
From: David Miller @ 2019-02-01 23:13 UTC (permalink / raw)
To: gustavo; +Cc: vishal, netdev, linux-kernel
In-Reply-To: <20190131002744.GA26706@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 30 Jan 2019 18:27:44 -0600
> One of the more common cases of allocation size calculations is
> finding the size of a structure that has a zero-sized array at
> the end, along with memory for some number of elements for that
> array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: tls: Set async_capable for tls zerocopy only if we see EINPROGRESS
From: David Miller @ 2019-02-01 23:05 UTC (permalink / raw)
To: davejwatson; +Cc: netdev, vakul.garg, borisp, aviadye, john.fastabend, daniel
In-Reply-To: <20190130220819.wgwenjanlzftvb6i@davejwatson-mba.local>
From: Dave Watson <davejwatson@fb.com>
Date: Wed, 30 Jan 2019 22:08:21 +0000
> Currently we don't zerocopy if the crypto framework async bit is set.
> However some crypto algorithms (such as x86 AESNI) support async,
> but in the context of sendmsg, will never run asynchronously. Instead,
> check for actual EINPROGRESS return code before assuming algorithm is
> async.
>
> Signed-off-by: Dave Watson <davejwatson@fb.com>
Applied, thanks.
^ 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