Hi, > I think you should change our in kernel nfnetlink_queue backend > to use a single hash table to store nf_entry. > > You can use rhashtable, and hash via > > hash(netns, queueid, packetid, secret); > > to avoid the linear searches in kernel. > This will unfortunately need repeated lookups for the VERDICT_BATCH > case though so we might end up needing two hash tables (2nd one would > a rhlist one that just hashes lists via hash(netns, queueid, secret), > used by VERDICT_BATCH. This seems doable for me. The problem is that we use kernel, with some modifications in the tcp stack, which is provided/maintained by a different company. I can see no way, at least currently, the other company to allow us to do changes in the kernel that they provide. The only way, we've done some things in the kernel so far, was through kernel modules which we developed and tested against the main stream kernel and the other company produced the final build of the modules. That's the reason I was searching for a solution with a kernel module. > It might be possible to avoid that by combining nfqueue with -m > hashlimit and a small timeout (or nft flow statement) instead. > > Or do you consider that too broken? I didn't think about it. It seems acceptable. The only cons, if I understand it correctly, is that some connections may get slightly more delay because it may drop the first syns for a some tcp connections, for others it may drop the first and the some of the re-transmitted syns. This way for some connections the syn packet which will provoke checking of the origin will be additionally delayed. Thanks for the response, Pavel. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
