Do you really care about latency? Or just overall performance (which is limited by the sum of the per-element latency)? Are these measurements when _new_ mappings are being created or using existing mappings?
Are these packets unique already? or is expensive_uniquify being called? You can try and get a profile using oprofile (which should work even on click in the kernel I believe) or using userlevel click + google-perftools. If you want more detail about what is slowing things down. Cliff On Thu, Dec 17, 2009 at 2:25 PM, Latency Buster <[email protected]>wrote: > Does anyone has a rough estimate of the port to port latency of NAT > using Click? I'm using a combination of IPClassifier, IPRewriter and > seeing the port to port latency varying between between 20 - 30 us. > This is when the IPRewriter has a single mapping instance and I am > using PollDevice for pulling packets. > > rw :: IPRewriter ( // > pattern 192.16.13.24 - 192.16.14.26 - 0 1, //Active > ) > > > A related question: What's the approach to nail down the most delay > prone element along the packet path inside Click? In my instance, > Click is running on Intel Xeon processor (quad core), PCIe cards and > with 8GB RAM. > > > Thanks, > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
