lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <574F50B7.10406@iogearbox.net> Date: Wed, 01 Jun 2016 23:16:39 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: Alexei Starovoitov <alexei.starovoitov@...il.com> CC: Jakub Kicinski <jakub.kicinski@...ronome.com>, netdev@...r.kernel.org, ast@...nel.org, dinan.gunawardena@...ronome.com Subject: Re: [RFC 06/12] nfp: add hardware cls_bpf offload On 06/01/2016 10:52 PM, Alexei Starovoitov wrote: > On Wed, Jun 01, 2016 at 10:20:54PM +0200, Daniel Borkmann wrote: >> On 06/01/2016 06:50 PM, Jakub Kicinski wrote: >>> Add hardware cls_bpf offload on our smart NICs. Detect if >>> capable firmware is loaded and use it to load the code JITed >>> with just added translator onto programmable engines. >>> >>> Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com> >>> Reviewed-by: Dinan Gunawardena <dgunawardena@...ronome.com> >>> Reviewed-by: Simon Horman <simon.horman@...ronome.com> >> [...] >>> +static int >>> +nfp_net_bpf_offload_prepare(struct nfp_net *nn, >>> + struct tc_cls_bpf_offload *cls_bpf, >>> + struct nfp_bpf_result *res, >>> + void **code, dma_addr_t *dma_addr, u16 max_instr) >>> +{ >>> + unsigned int code_sz = max_instr * sizeof(u64); >>> + u16 start_off, tgt_out, tgt_abort; >>> + const struct tc_action *a; >>> + int err; >>> + >>> + if (tc_no_actions(cls_bpf->exts)) >>> + return -EINVAL; >>> + >>> + tc_for_each_action(a, cls_bpf->exts) { >>> + if (!is_tcf_gact_shot(a)) >>> + return -EINVAL; >>> + } >>> + >>> + if (cls_bpf->exts_integrated) >>> + return -EINVAL; >> >> So cls_bpf has two working modes as mentioned: da (direct-action) and non-da. >> Direct-action is I would say the most typical way to run cls_bpf as it allows >> you to more naturally and efficiently code programs in the sense that classification >> and action is already combined in a single program, so there's no additional >> overhead of a linear action chain required, and a single program can already >> have multiple action code outcomes (TC_ACT_OK, TC_ACT_SHOT, ...), so that it is >> usually enough to run a single cls_bpf instance, for example, on sch_clsact >> ingress or egress parent, nothing more than that to get the job done. I think >> the cls_bpf->exts_integrated test could probably come first and if it's false, >> we'd need to walk the actions? > > I think it makes sense to offload da mode only. Doing tc_for_each_action > walk like above is ok, but the number of bpf programs with only separate > gact is diminishingly small and we don't recommend to use it anymore. > That's the stuff we used when da wasn't available. Yeah, that makes sense to me, I presume that would also be easier to manage due to all being self-contained.
Powered by blists - more mailing lists