[ovs-discuss] Upcall to userspace threading question

Jesse Gross jesse at nicira.com
Sat Jun 13 03:02:05 UTC 2015


On Fri, Jun 12, 2015 at 5:29 AM, Scott Daniels <daniels at research.att.com> wrote:
> Currently flow setup is done in a round-robin manner based on port to
> prevent the possibility of a denial of service attack.  However, in a
> situation where all GRE tunnels terminate on a single port (specifically in
> the case of an L3 node under Openstack) it seems to make sense to further
> split the flow setup from a single port to prevent the possibility of a
> similar DoS attack that affects the GRE traffic.
>
> Has this split been considered, and if so are there reasons that it wasn't
> implemented?

This isn't entirely true any more (it used to be). Each port now has
an array of sockets that packets can be queued to and flows are spread
among them based on a hash of the flow.

> Somewhat related, when an action list contains a sample action it causes the
> packet to be cloned and sent to userspace. The way I read it the samples
> share the same upcall path as flow setup upcalls. Given that sampling would
> be pushing larger packets into the upcall path, compared to SYNs during flow
> setup, I assume that if the sampling rate were too aggressive that this
> could lead to a full upcall queue which would have a negative impact on
> other traffic.
>
> Has there been any thought given to splitting the sampling upcalls from the
> rest of the upcall "traffic?"

It's possible to implement this given the existing kernel
infrastructure but I haven't heard this being an issue before and so
nobody has bothered to do it to the best of my knowledge. Other types
of control packets - STP, CFM, etc. - are sent to a separate queue.



More information about the discuss mailing list