Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > ID assignment is lockless: this patch divides the 64-bit space between > > > > Why do we need an id in the first place? > > Can you elaborate? > > It's a userspace thing, for statistics and manipulation via ctnetlink, > eg. delete an entry. To make sure you refer to the same conntrack > entry when polling for statistics and also for events, in case of > event loss, you keep context around in case tear-down and re-creation > happens in little time. Hmm. I think for that use case (e.g. do not delete an entry unless it is the one we initally saw via NEW in case we missed a DELETE in between even my jhash based patch in patch work is good enough. However, in most realistic cases there never was such a gurantee, see below. > > As far as I know there is no need for this ID at all, > > the netlink attribute is only provided for backwards compat. > > > > And for that the suggested approach (hash of tuple and memory > > addresses) will work just fine. > > It's still possible to land a conntrack with exactly the same tuple on > the same memory address. Sure, but the chances are already pretty much close to 0. Remember that we can have connection re-use while conntrack object remains unchanged (e.g. new SYN while contrack is in TW). The ID doesn't change in this case even with the old approach. ANd what are the chances of a full tuple reuse *right* at the moment of expiry (i.e. before any other new allocation)? And why would we treat it differently than syn-in-tw case? > I can just keep this patchset back and push the one that randomizes > what we dump to userspace (ie. 3/3), I don't need this now, it's just > a patchset that it's been stuck in my tree for a while. I am fine with 3/3. You might want to use hash_ptr anyway just in case though (and perhaps include ct->ext). -- 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
