On Thu, Nov 05, 2020 at 09:02:15AM -0700, David Ahern wrote:
> On 11/5/20 8:57 AM, Toke Høiland-Jørgensen wrote:
> > I guess we could split it further into lib/bpf_{libbpf,legacy,glue}.c
> > and have the two former ones be completely devoid of ifdefs and
> > conditionally included based on whether
On Thu, Nov 05, 2020 at 08:25:12AM -0700, David Ahern wrote:
> > Sorry, when trying to rename the functions. I just found another issue.
> > Even we fix the conflicts right now. What if libbpf add new functions
> > and we got another conflict in future? There are too much bpf functions
> > in bpf_l
On 11/5/20 8:57 AM, Toke Høiland-Jørgensen wrote:
> I guess we could split it further into lib/bpf_{libbpf,legacy,glue}.c
> and have the two former ones be completely devoid of ifdefs and
> conditionally included based on whether or not libbpf support is
> enabled?
that sounds reasonable.
David Ahern writes:
> On 11/5/20 12:51 AM, Hangbin Liu wrote:
>> On Wed, Nov 04, 2020 at 07:33:40PM -0700, David Ahern wrote:
>>> On 11/4/20 1:22 AM, Hangbin Liu wrote:
If we move this #ifdef HAVE_LIBBPF to bpf_legacy.c, we need to rename
them all. With current patch, we limit all the l
On 11/5/20 12:51 AM, Hangbin Liu wrote:
> On Wed, Nov 04, 2020 at 07:33:40PM -0700, David Ahern wrote:
>> On 11/4/20 1:22 AM, Hangbin Liu wrote:
>>> If we move this #ifdef HAVE_LIBBPF to bpf_legacy.c, we need to rename
>>> them all. With current patch, we limit all the legacy functions in
>>> bpf_
On Wed, Nov 04, 2020 at 07:33:40PM -0700, David Ahern wrote:
> On 11/4/20 1:22 AM, Hangbin Liu wrote:
> > If we move this #ifdef HAVE_LIBBPF to bpf_legacy.c, we need to rename
> > them all. With current patch, we limit all the legacy functions in
> > bpf_legacy
> > and doesn't mix them with libbpf
On 11/4/20 1:22 AM, Hangbin Liu wrote:
> If we move this #ifdef HAVE_LIBBPF to bpf_legacy.c, we need to rename
> them all. With current patch, we limit all the legacy functions in bpf_legacy
> and doesn't mix them with libbpf.h. What do you think?
Let's rename conflicts with a prefix -- like legac
On Mon, Nov 02, 2020 at 08:41:09AM -0700, David Ahern wrote:
> On 10/29/20 9:11 AM, Hangbin Liu wrote:
> > diff --git a/ip/ipvrf.c b/ip/ipvrf.c
> > index 33150ac2..afaf1de7 100644
> > --- a/ip/ipvrf.c
> > +++ b/ip/ipvrf.c
> > @@ -28,8 +28,14 @@
> > #include "rt_names.h"
> > #include "utils.h"
> >
On 11/2/20 10:48 PM, Hangbin Liu wrote:
>
> The iproute2_* functions need access static struct bpf_elf_ctx __ctx;
> We need move the struct bpf_elf_ctx to another header file if add the
> iproute2_* functions to compat file. Do you still want this?
>
ok, leave it in legacy for now.
On Mon, Nov 02, 2020 at 08:41:09AM -0700, David Ahern wrote:
>
> I would prefer to have these #ifdef .. #endif checks consolidated in the
> lib code. Create a bpf_compat file for these. e.g.,
>
> int bpf_program_load(enum bpf_prog_type type, const struct bpf_insn *insns,
> si
On 10/29/20 9:11 AM, Hangbin Liu wrote:
> diff --git a/ip/ipvrf.c b/ip/ipvrf.c
> index 33150ac2..afaf1de7 100644
> --- a/ip/ipvrf.c
> +++ b/ip/ipvrf.c
> @@ -28,8 +28,14 @@
> #include "rt_names.h"
> #include "utils.h"
> #include "ip_common.h"
> +
> #include "bpf_util.h"
>
> +#ifdef HAVE_LIBBPF
This patch converts iproute2 to use libbpf for loading and attaching
BPF programs when it is available, which is started by Toke's
implementation[1]. With libbpf iproute2 could correctly process BTF
information and support the new-style BTF-defined maps, while keeping
compatibility with the old int
12 matches
Mail list logo
