Re: [iovisor-dev] [PATCH RFC 3/4] New 32-bit register set
Hi, Jiong, The new patch looks good. I did some basic testing on net-next:samples/bpf and net-next:tools/testing/selftests/bpf and it works fine. All existing llvm unit tests are not impacted as well as expected. I have applied the patch to the trunk. Besides your other work to support 32bit abi, it would be interesting to see how new 32bit register can be used in 64bit architecture which may help improve performance and/or reduce instruction count. Thanks, Yonghong On Tue, Sep 19, 2017 at 4:10 PM, Jiong Wang wrote: > On 19/09/2017 07:44, Y Song wrote: >> >> Hi, Jiong, >> >> Thanks for the patch! It is a great start to support 32bit register in >> BPF. >> In the past, I have studied a little bit to see whether 32bit register >> support may reduce >> the number of unnecessary shifts on x86_64 and improve the >> performance. Looking through >> a few bpf programs and it looks like the opportunity is not great, but >> still nice to have if we >> have this capability. As you mentioned, this definitely helped 32bit >> architecture! >> >> I am not an expert in LLVM tablegen. I briefly looked through the code >> change and it looks like >> correct. Hopefully some llvm-dev tablegen experts can comment on the >> implementation. >> >> Below I only have a couple of minor comments. > > > Yong Hong, > > Thanks for the review. > > I have addressed your comments and attached the updated patch. > > Do you want me to put this patch set on to llvm review website? I guess it > is the > formal review channel? > > Regards, > Jiong > ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] eBPF prog getting rejected with devmap (and cpumap)
On Thu, 21 Sep 2017 22:06:27 +0200
Daniel Borkmann wrote:
> On 09/21/2017 10:02 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
> > Hi Daniel,
> >
> > My very simple program is getting rejected on bpf loading time. When
> > using another map as input for a decision, for map type BPF_MAP_TYPE_DEVMAP.
> >
> > SEC("xdp_redirect_map_rr")
> > int xdp_prog_redirect_map_rr(struct xdp_md *ctx)
> > {
> > void *data_end = (void *)(long)ctx->data_end;
> > void *data = (void *)(long)ctx->data;
> > struct ethhdr *eth = data;
> > int vport = 0;
> > u32 key = 0;
> > long *value;
> >
> > // count packet in global counter
> > value = bpf_map_lookup_elem(&rxcnt, &key);
> > if (value)
> > *value += 1;
> >
> > /* Strange, verifier reject this (with LLVM version 3.9.1) */
> > vport = *value % 2;
>
> Here it's dereferenced where above it could have been NULL
> from the lookup, so verifier is correct. You'd need to place
> it into the if clause above or just do 'if (!value) return XDP_ABORTED'
> or the like.
Ah, I see! Thanks for the quick answer and solution :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
___
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] eBPF prog getting rejected with devmap (and cpumap)
On 09/21/2017 10:02 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
Hi Daniel,
My very simple program is getting rejected on bpf loading time. When
using another map as input for a decision, for map type BPF_MAP_TYPE_DEVMAP.
SEC("xdp_redirect_map_rr")
int xdp_prog_redirect_map_rr(struct xdp_md *ctx)
{
void *data_end = (void *)(long)ctx->data_end;
void *data = (void *)(long)ctx->data;
struct ethhdr *eth = data;
int vport = 0;
u32 key = 0;
long *value;
// count packet in global counter
value = bpf_map_lookup_elem(&rxcnt, &key);
if (value)
*value += 1;
/* Strange, verifier reject this (with LLVM version 3.9.1) */
vport = *value % 2;
Here it's dereferenced where above it could have been NULL
from the lookup, so verifier is correct. You'd need to place
it into the if clause above or just do 'if (!value) return XDP_ABORTED'
or the like.
if (vport >= 10)
return XDP_ABORTED;
return bpf_redirect_map(&tx_port, vport, 0);
}
bpf_load_program() err=13
0: (b7) r6 = 0
1: (63) *(u32 *)(r10 -4) = r6
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = 0x880832682700
6: (85) call bpf_map_lookup_elem#1
7: (79) r2 = *(u64 *)(r0 +0)
R0 invalid mem access 'map_value_or_null'
Are we missing something verifier code for BPF_MAP_TYPE_DEVMAP ?
___
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
[iovisor-dev] eBPF prog getting rejected with devmap (and cpumap)
Hi Daniel,
My very simple program is getting rejected on bpf loading time. When
using another map as input for a decision, for map type BPF_MAP_TYPE_DEVMAP.
SEC("xdp_redirect_map_rr")
int xdp_prog_redirect_map_rr(struct xdp_md *ctx)
{
void *data_end = (void *)(long)ctx->data_end;
void *data = (void *)(long)ctx->data;
struct ethhdr *eth = data;
int vport = 0;
u32 key = 0;
long *value;
// count packet in global counter
value = bpf_map_lookup_elem(&rxcnt, &key);
if (value)
*value += 1;
/* Strange, verifier reject this (with LLVM version 3.9.1) */
vport = *value % 2;
if (vport >= 10)
return XDP_ABORTED;
return bpf_redirect_map(&tx_port, vport, 0);
}
bpf_load_program() err=13
0: (b7) r6 = 0
1: (63) *(u32 *)(r10 -4) = r6
2: (bf) r2 = r10
3: (07) r2 += -4
4: (18) r1 = 0x880832682700
6: (85) call bpf_map_lookup_elem#1
7: (79) r2 = *(u64 *)(r0 +0)
R0 invalid mem access 'map_value_or_null'
Are we missing something verifier code for BPF_MAP_TYPE_DEVMAP ?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
___
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] [PATCH RFC 0/4] Initial 32-bit eBPF encoding support
On 09/21/2017 08:56 PM, Alexei Starovoitov wrote: On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: On 18/09/2017 22:29, Daniel Borkmann wrote: On 09/18/2017 10:47 PM, Jiong Wang wrote: Hi, Currently, LLVM eBPF backend always generate code in 64-bit mode, this may cause troubles when JITing to 32-bit targets. For example, it is quite common for XDP eBPF program to access some packet fields through base + offset that the default eBPF will generate BPF_ALU64 for the address formation, later when JITing to 32-bit hardware, BPF_ALU64 needs to be expanded into 32 bit ALU sequences even though the address space is 32-bit that the high bits is not significant. While a complete 32-bit mode implemention may need an new ABI (something like -target-abi=ilp32), this patch set first add some initial code so we could construct 32-bit eBPF tests through hand-written assembly. A new 32-bit register set is introduced, its name is with "w" prefix and LLVM assembler will encode statements like "w1 += w2" into the following 8-bit code field: BPF_ADD | BPF_X | BPF_ALU BPF_ALU will be used instead of BPF_ALU64. NOTE, currently you can only use "w" register with ALU statements, not with others like branches etc as they don't have different encoding for 32-bit target. Great to see work in this direction! Can we also enable to use / emit all the 32bit BPF_ALU instructions whenever possible for the currently available bpf targets while at it (which only use BPF_ALU64 right now)? Hi Daniel, Thanks for the feedback. I think we could also enable the use of all the 32bit BPF_ALU under currently available bpf targets. As we now have 32bit register set support, we could make i32 type as legal type to prevent it be promoted into i64, then hook it up with i32 ALU patterns, will look into this. I don't think we need to gate 32bit alu generation with a flag. Though interpreter and JITs support 32-bit since day one, the verifier never seen such programs before, so some valid programs may get rejected. After some time passes and we're sure that all progs still work fine when they're optimized with 32-bit alu, we can flip the switch in llvm and make it default. Sounds good to me! Could this be done for bpf target via -mattr=+alu32 feature flag or similar in llc? ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] [PATCH RFC 0/4] Initial 32-bit eBPF encoding support
On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: > On 18/09/2017 22:29, Daniel Borkmann wrote: > > On 09/18/2017 10:47 PM, Jiong Wang wrote: > > > Hi, > > > > > > Currently, LLVM eBPF backend always generate code in 64-bit mode, > > > this may > > > cause troubles when JITing to 32-bit targets. > > > > > > For example, it is quite common for XDP eBPF program to access > > > some packet > > > fields through base + offset that the default eBPF will generate > > > BPF_ALU64 for > > > the address formation, later when JITing to 32-bit hardware, > > > BPF_ALU64 needs > > > to be expanded into 32 bit ALU sequences even though the address > > > space is > > > 32-bit that the high bits is not significant. > > > > > > While a complete 32-bit mode implemention may need an new ABI > > > (something like > > > -target-abi=ilp32), this patch set first add some initial code so we > > > could > > > construct 32-bit eBPF tests through hand-written assembly. > > > > > > A new 32-bit register set is introduced, its name is with "w" > > > prefix and LLVM > > > assembler will encode statements like "w1 += w2" into the following > > > 8-bit code > > > field: > > > > > > BPF_ADD | BPF_X | BPF_ALU > > > > > > BPF_ALU will be used instead of BPF_ALU64. > > > > > > NOTE, currently you can only use "w" register with ALU > > > statements, not with > > > others like branches etc as they don't have different encoding for > > > 32-bit > > > target. > > > > Great to see work in this direction! Can we also enable to use / emit > > all the 32bit BPF_ALU instructions whenever possible for the currently > > available bpf targets while at it (which only use BPF_ALU64 right now)? > > Hi Daniel, > > Thanks for the feedback. > > I think we could also enable the use of all the 32bit BPF_ALU under > currently > available bpf targets. As we now have 32bit register set support, we could > make > i32 type as legal type to prevent it be promoted into i64, then hook it up > with i32 > ALU patterns, will look into this. I don't think we need to gate 32bit alu generation with a flag. Though interpreter and JITs support 32-bit since day one, the verifier never seen such programs before, so some valid programs may get rejected. After some time passes and we're sure that all progs still work fine when they're optimized with 32-bit alu, we can flip the switch in llvm and make it default. ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
[iovisor-dev] minutes: IO Visor TSC/Dev meeting
Hi All, Thanks for attending the call yesterday, here are my notes: === News === Linux Plumbers was last week, and included an increasing focus on BPF for tracing and other use cases over previous years. The tracing/BPF track on Friday had a very packed agenda, only allowing 10-15 minutes per talk. For full notes on the discussions, please check out the etherpad at: https://etherpad.openstack.org/p/LPC2017_Tracing Other upcoming conferences: Kernel Recipes - Sept 27-29 https://kernel-recipes.org/en/2017/ Brendan - Performance Analysis with BPF Netdev 2.2 - Nov 8-10 https://netdevconf.org/2.2/ Last day to submit a talk was yesterday, registration is still open === Developer Status === Brenden - Work started on a LLVM Debug Info traverser for BCC - Should be able to generate CTF data Martin - Investigating CTF converter for use in kernel Jesper - new map type - cpu - like netdev map - redirecting to another cpu - example: ddos on first cpu - queue non-dropped packets to other cpu - other cpu allocs skb Martin - worked on tool to iterate over bpf programs and which maps they are using - Nic suggests a similar tool from Jakub to iterate programs - https://github.com/Netronome/bpf-tool Jiong - Working on 32 bit bpf backend in llvm - (makes netronome happy) - Please let the community know when something is ready and we can help with testing :) === Attendees === Panagiotis Moustafellos Nic Viljoen Mauricio Vasquez Martin Lau Marco Leogrande Jiong Jesper Brouer Jakub Kicinski Edwin Peer Brenden Blanco Brendan Gregg Alexander Duyck Abder ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
