This reply was resent as the previous email had a missing In-Reply-To
in the header.
> > > On Mon, 2025-02-10 at 16:06 -0800, Andrii Nakryiko wrote:
> > > > Tracking associated maps for a program is not necessary. As long as
> > > > the last BPF program using the BPF map is unloaded, the kernel wi
> > > On Mon, 2025-02-10 at 16:06 -0800, Andrii Nakryiko wrote:
> > > > Tracking associated maps for a program is not necessary. As long as
> > > > the last BPF program using the BPF map is unloaded, the kernel will
> > > > automatically free not-anymore-referenced BPF map. Note that
> > > > bpf_ob
On Wed, Feb 12, 2025 at 2:31 PM Martin Kelly
wrote:
>
> On Mon, 2025-02-10 at 16:06 -0800, Andrii Nakryiko wrote:
> > > Tracking associated maps for a program is not necessary. As long as
> > > the last BPF program using the BPF map is unloaded, the kernel will
> > > automatically free not-anymore
On Mon, 2025-02-10 at 16:06 -0800, Andrii Nakryiko wrote:
> > Tracking associated maps for a program is not necessary. As long as
> > the last BPF program using the BPF map is unloaded, the kernel will
> > automatically free not-anymore-referenced BPF map. Note that
> > bpf_object itself will keep
On Fri, Feb 7, 2025 at 5:13 PM Martin Kelly
wrote:
>
> On Wed, 2025-02-05 at 14:33 -0800, Andrii Nakryiko wrote:
> > > > >
> > > > > I see two ways forward for you. Either you can break apart your
> > > > > BPF
> > > > > object of ~100 BPF programs into more independent BPF objects >
> > > > > > (
On Wed, 2025-02-05 at 14:33 -0800, Andrii Nakryiko wrote:
> > > >
> > > > I see two ways forward for you. Either you can break apart your
> > > > BPF
> > > > object of ~100 BPF programs into more independent BPF objects >
> > > > > (seeing
> > > > that programs can be independently loaded/unloaded
6 matches
Mail list logo
