[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210521060045.ldwluzdt3vyp5vfs@amnesia>
Date: Fri, 21 May 2021 10:00:45 +0400
From: Dmitrii Banshchikov <me@...que.spb.ru>
To: Song Liu <songliubraving@...com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
"open list:BPF (Safe dynamic programs and tools)"
<bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"andrii@...nel.org" <andrii@...nel.org>, Martin Lau <kafai@...com>,
Yonghong Song <yhs@...com>,
"john.fastabend@...il.com" <john.fastabend@...il.com>,
"kpsingh@...nel.org" <kpsingh@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Andrey Ignatov <rdna@...com>
Subject: Re: [PATCH bpf-next 00/11] bpfilter
On Thu, May 20, 2021 at 05:56:30PM +0000, Song Liu wrote:
>
>
> > On May 20, 2021, at 9:55 AM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> >
> > On Thu, May 20, 2021 at 12:53 AM Dmitrii Banshchikov <me@...que.spb.ru> wrote:
> >>
> >> On Thu, May 20, 2021 at 04:54:45AM +0000, Song Liu wrote:
> >>>
> >>>
> >>>> On May 17, 2021, at 3:52 PM, Dmitrii Banshchikov <me@...que.spb.ru> wrote:
> >>>>
> >>>> The patchset is based on the patches from David S. Miller [1] and Daniel
> >>>> Borkmann [2].
> >>>>
> >>>> The main goal of the patchset is to prepare bpfilter for iptables'
> >>>> configuration blob parsing and code generation.
> >>>>
> >>>> The patchset introduces data structures and code for matches, targets, rules
> >>>> and tables.
> >>>>
> >>>> It seems inconvenient to continue to use the same blob internally in bpfilter
> >>>> in parts other than the blob parsing. That is why a superstructure with native
> >>>> types is introduced. It provides a more convenient way to iterate over the blob
> >>>> and limit the crazy structs widespread in the bpfilter code.
> >>>>
> >>>
> >>> [...]
> >>>
> >>>>
> >>>>
> >>>> 1. https://lore.kernel.org/patchwork/patch/902785/
> >>>
> >>> [1] used bpfilter_ prefix on struct definitions, like "struct bpfilter_target"
> >>> I think we should do the same in this version. (Or were there discussions on
> >>> removing the prefix?).
> >>
> >> There were no discussions about it.
> >> As those structs are private to bpfilter I assumed that it is
> >> safe to save some characters.
> >> I will add the prefix to all internal structs in the next
> >> iteration.
> >
> > For internal types it's ok to skip the prefix otherwise it's too verbose.
> > In libbpf we skip 'bpf_' prefix in such cases.
>
> Do we have plan to put some of this logic in a library? If that is the case, the
> effort now may save some pain in the future.
I cannot imagine a case when we need this logic in a library.
Even if we eventually need it as these definitions are private to
bpfilter - amount of pain should be minimal.
>
> Thanks,
> Song
>
--
Dmitrii Banshchikov
Powered by blists - more mailing lists