> 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.
