Messages in this thread | | | Date | Tue, 27 Jun 2023 08:51:47 -0600 | From | Daniel Xu <> | Subject | Re: [PATCH bpf-next 0/7] Support defragmenting IPv(4|6) packets in BPF |
| |
Hi Toke,
Thanks for taking a look at the patchset.
On Tue, Jun 27, 2023 at 04:25:13PM +0200, Toke Høiland-Jørgensen wrote: > > The basic idea is we bump a refcnt on the netfilter defrag module and > > then run the bpf prog after the defrag module runs. This allows bpf > > progs to transparently see full, reassembled packets. The nice thing > > about this is that progs don't have to carry around logic to detect > > fragments. > > One high-level comment after glancing through the series: Instead of > allocating a flag specifically for the defrag module, why not support > loading (and holding) arbitrary netfilter modules in the UAPI? If we > need to allocate a new flag every time someone wants to use a netfilter > module along with BPF we'll run out of flags pretty quickly :)
I don't have enough context on netfilter in general to say if it'd be generically useful -- perhaps Florian can comment on that.
However, I'm not sure such a mechanism removes the need for a flag. The netfilter defrag modules still need to be called into to bump the refcnt.
The module could export some kfuncs to inc/dec the refcnt, but it'd be rather odd for prog code to think about the lifetime of the attachment (as inc/dec for _each_ prog execution seems wasteful and slow). AFAIK all the other resource acquire/release APIs are for a single prog execution.
So a flag for link attach feels the most natural to me. We could always add a flag2 field or something right?
[...]
Thanks, Daniel
| |