About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Wed, 20 Dec 2006

Network address translation (NAT) works over netchannels.


One can add/remove source/destination NAT using connector (Documentation/connector/ in your source tree).
NAT over netchannels uses two aditional netchannels per dataflow (input and output from NAT server point of view) and one main (what administrator sets up using source/destination rules) as I described previously.
It uses the same tries as other netchannels (userspace or others), so only one lookup is performed to transfer packet.
Packet processing happens in process context on behalf of special threads, dedicated specially for netchannel processing, when packet enters netchannel stack and netchannel has been selected, it is possible to schedule its processing either to current thread, or to thread on other CPU.
Netchannel searching is lockless (protected by RCU), skb queueing is proceted by spinlock.

So, brief list of netchannel features:

• multidimensional wildcards support
• RCU searching
• single multidimensional trie for different kinds of dataflows
• dedicated processing threads with possibility to schedule processing on different CPUs for those netchannel types which are not acked with processing context
• userspace netchannel backend (allows to receive packets to userspace), which can be used for:
  • high-performance sniffers
  • tun/tap device replacement
  • packet socket replacement (note, that netchannels steal packets from main stack)
  • userspace network stack implementation
  • own protocol stack implementaion (from VPN tunnels to TOE)
• netfilter netchannel backend (only NAT is supported as the most interesting user, NAT caches appropriate route, so essentially routing becomes part of the netchannel trie)

/devel/networking :: Link / Comments ()