netdev - Re: [PATCH bpf-next v5 2/3] libbpf: add low level TC-BPF API

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210503231120.aqp5476l7jfiy5ws@apollo>
Date:   Tue, 4 May 2021 04:41:20 +0530
From:   Kumar Kartikeya Dwivedi <memxor@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     bpf <bpf@...r.kernel.org>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Shaun Crampton <shaun@...era.io>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next v5 2/3] libbpf: add low level TC-BPF API

On Tue, May 04, 2021 at 04:24:05AM IST, Andrii Nakryiko wrote:
> On Fri, Apr 30, 2021 at 11:32 PM Kumar Kartikeya Dwivedi
> <memxor@...il.com> wrote:
> >
> > On Sat, May 01, 2021 at 01:05:40AM IST, Andrii Nakryiko wrote:
[...]
> > >
> > > why didn't you put flags into bpf_tc_opts? they are clearly optional
> > > and fit into "opts" paradigm...
> > >
> >
> > I can move this into opts, but during previous discussion it was kept outside
> > opts by Daniel, so I kept that unchanged.
>
> for bpf_tc_attach() I see no reason to keep flags separate. For
> bpf_tc_hook_create()... for extensibility it would need it's own opts
> for hook creation. But if flags is 99% the only thing we'll need, then
> we can always add extra bpf_tc_hook_create_opts() later.
>

I'll put flags in the respective opts struct for both.

The hook creation path was kept generic enough so that this can be extended to
complex qdisc setup in the future than just clsact (even classful qdiscs should
be possible). So it is quite possible for bpf_tc_hook to take more parameters
than just flags by mapping different attach_point to different qdiscs.

Given some parameters are already optional depending on attach_point, it is
probably better to put flags in opts than dropping opts for now.

--
Kartikeya