Hey Ben, Sorry for the delayed response. Unfortunately, I've had some issues with setting up an NVP perf environment lately so I haven't gotten any numbers. When I do, I'll publish them on this thread.
Ethan's rationale is that it simplifies the code and we don't incur the memory overhead of allocating a hash map and this would outweigh the negative effect of possibly re-processing a packet from the same flow. Since userspace forwarding has gotten so much faster, this wouldn't be so bad. Obviously, I need perf numbers to justify these claims; I will post them when I do. Ryan Wilson Member of Technical Staff wr...@vmware.com 3401 Hillview Avenue, Palo Alto, CA 650.427.1511 Office 916.588.7783 Mobile On May 9, 2014, at 8:25 AM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, May 07, 2014 at 03:14:01PM -0700, Ryan Wilson wrote: >> The upcall hander keeps a hash table which hashes flow to a list of >> corresponding packets. This used to be necessary as packets with the same >> flow >> had similar actions and calculating actions used to be a performance >> bottleneck. >> Now that userspace action calculation performance has improved, there is no >> need >> for this hash map. >> >> This patch removes this hash map and each packet has its own upcall. >> >> Signed-off-by: Ryan Wilson <wr...@nicira.com> > > Hmm. Do we have performance numbers to back this up? Ethan, I assume > that you suggested this project; do you have additional rationale?
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
