Manohar Krishnappa Chidambaraswamy
> 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
dev mailing list