On Fri, Dec 5, 2014 at 2:38 AM, Matthew Dillon <[email protected]> wrote: > On how to make NAT work, what I did in PF was this: > > (a) When the port is not locked to a particular number, I simply iterate > ports until the toepliz hash for the translated address/port pair > winds up on the same cpu as the toeplez hash of the original. > > This way both sides of the NAT conversation wind up on the same cpu > and no locking is required. > > (b) If the translated port is locked (which is a feature that PF has, > for example), it may not be possible to match up the toeplez hash. > > In this situation the state goes into a global table with a global > lock, and the state is individually locked by the filter. >
In addition to what Matt has mentioned, I think lockless NAT could be implemented in the following way: - On output path install state for the current netisr. And rehash the packet then send to the target netisr, and install 'sibling state' in the target netisr; do the real output there. - Same applies to the input path; but do the protocol input in the target netisr. However, the result may not be better than or as good as per-cpu+global lock Matt implemented for the PF, since my way requires additional dispatch. Best Regards, sephe -- Tomorrow Will Never Die
