Manohar Krishnappa Chidambaraswamy <manohar.krishnappa.chidambarasw...@ericsson.com> writes:
> How are you stress testing this? Is there some framework you're using? > [manu] Since the number/rate of new flows coming in depends on the > deployment (expected traffic pattern), upcall ratelimit parameters > need to be tuned for a given deployment. We have only done functional > tests on this for now. Let me know when you figure out what framework / setup you're planning on using to stress this. > I'm interested in possibly implementing a similar rate-limiter from the > kernel side (for parity), but want to see if it's really a problem > with the netlink datapath first. > > [manu] In kernel path, slow-path and fast-path are executed in > different contexts, with slow-path executing in dedicated userspace > threads and fast-path in kernel. An upcall is posted from the kernel > module over netlink sockets (a.k.a queues) to upcall threads in > userspace. Hence the number of upcalls can be controlled by > controlling the depth of this queue. So token-bucket would be > unnecessary IMO. Sure, but you end up with similar starvation issues (well... in practice you end up out of file descriptors because of the number of upcall sockets opened - maybe you see why I'm interested in per-port rate limiting :) _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev