On Fri, 10 Aug 2018, Akshat Kakkar wrote: > > No, that's a totally wrong way. ipset is independent from > > iptables/ip6tables: you cannot refer to a match/target/chain from > > ipset. It also makes no sense to reimplement those in ipset. > > Yes. Thats obvious that iptables need to do decision handling, packet > flow, etc. Just that, I want to store that information in ipset using > which iptables can decide. Clearly, iptables also need to have support > of these modified/new ipset. That'd mean all those things should be interfaced via the SET target - too complicated and still would require a lot of modifications in iptables as well. > > If you miss functionality in nftables compared to ipset, then invest > > your energy in nftables instead. Dictionaries, maps are already there. > > This looks to me more promising from day 1. However, are all > functionalities of iptables, ipset incorporated in nftables? For eg., > can we store connmark and tc classid in skbinfo of named set in > nftables? I'd not worry about connmark/classid in nftables. Those are missing from nftables but I strongly believe it's simpler to add the support there. What's really missing from nftables yet is to handle real subnets in sets/maps/dicts. To add that feature needs more work and time. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary