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

Reply via email to