[ovs-discuss] ovs performance on 'worst case scenario' with ovs-vswitchd up to 100%

George Shuklin george.shuklin at gmail.com
Wed Mar 20 07:26:19 UTC 2013


20.03.2013 05:40, Jesse Gross пишет:
> On Mon, Mar 18, 2013 at 8:50 PM, George Shuklin
> <george.shuklin at gmail.com> wrote:
>> Why ovs-vswitchd can't feed kernel with very simple 'kernel flow' 'drop all'
>> after some smart and exact rules for arp?
>>
>> Why UDP is parsed so deep?
>>
>> Is any way to feed kernel module with fast generic rules without passing
>> every new flow to the userspace?
> Directly moving classification logic into the kernel as you describe
> is either not very general purpose (i.e. having special logic for
> "drop everything except ARP") or not very performant/good design (it
> ends up moving much more logic into the fast path).  There is ongoing
> work to improve performance in this area but it is a non-trivial
> problem.
Yep, I'm digging into openvswitch kernel module. I think I'll change 
ovs_flow_extract() to change depth on inspection depends on port number.

In my opinion, main problem for OVS is lack of mask in kernel path, so 
every new packet with different UDP/TCP ports is forwarded to userspace. 
If only rules can say 'all udp' or 'all traffic for ip_src xxx' it can 
drastically improve performance for the worst case scenario.

I know that OVS makes hash for key, extracted from packet header, and 
than search flow table for the match  - so no masks of any kind allowed, 
but, for example, can it be few different algorithms for 
ovs_flow_extract and some mechanism to set different algorithm for 
different interfaces.

Right now situation is almost critical, because any server with 10G 
interface with OVS as softswitch can be shut down from simple attack of 
microscopic size (about 10-15Mb/s).



More information about the discuss mailing list