Re: nft set load metrics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Presumably it was you who created the elements, can you not simply
> store them e.g. in a Perl hash at the time they're created?  I do
> something similar using Net::CIDR::Lite.  (I would never claim that a
> Perl script is the most efficient way of doing it, nor anything else
> for that matter, but it gets the job done. :)

cristian: you are basically proposing a kind of user space cache of
kernel nft sets maintained by the application which pushes the
rules/sets to the kernel.

I have also thought of that. it can get complicated though especially
when the sets are dynamic, with their entries expiring. implementing
performant timers in application is yet another beast to deal with...

On Thu, Sep 30, 2021 at 7:35 PM G.W. Haywood <ged@xxxxxxxxxxxxxxxxxx> wrote:
>
> Hi there,
>
> On Thu, 30 Sep 2021, Cristian Constantin wrote:
>
> > ... reading large packets over netlink sockets just to count the
> > elements in the sets does not seem very efficient.
>
> Agreed.
>
> It seems to me that if you need to read what you've put in the sets
> for the purposes of some facility, then you need to store it in RAM.
>
> It doesn't make sense to me to try to use netfilter as a kind of RAM;
> as you say that will be very inefficient.
>
> Presumably it was you who created the elements, can you not simply
> store them e.g. in a Perl hash at the time they're created?  I do
> something similar using Net::CIDR::Lite.  (I would never claim that a
> Perl script is the most efficient way of doing it, nor anything else
> for that matter, but it gets the job done. :)
>
> --
>
> 73,
> Ged.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux