Hello all,

I test Open vSwitch in the following scheme: I use 2 hosts directly
connected to OVS and external OpenFlow Controller. Host1 generates UDP
datagrams with sequential ports towards Host2, Host 2 listens for these UDP
datagrams. In responce to every UDP datagram OVS generates Packet_In and
Controller sends Flow_Mod back with L4 granularity (so for every pair of
UDP port numbers it installs separate flow). I send bunch of UDP datagrams
from Host1 and calculate how many of them arrived to Host2. I tried both
with detached controller and running in the same machine as OVS. I tested
it on different machines (in Mininet and with separated real hosts). I use
out-of-band option for controller and disable-in-band=true.


Starting  some number of packets ( around >300) packet drops are observed.
For instance, if I generate 500 UDP packets in 120 ms only around 350 of
them arrive to Host2 (Subsequent packets of the same flow can arrive to
Host2, but first packets of flows always experience drops)


ovs-ofctl dump-aggregate show that all the flows are installed but only
part of packets are processed through them:

NXST_AGGREGATE reply (xid=0x4): packet_count=356 byte_count=42364
flow_count=500


ovs-ofctl dump-ports also shows that 500 packets arrive on ingress
interface and only 356 leave egress.


ovs-dpctl show –s shows the same –  500 flows installed and 356 packets
processed.


Also I tried to replace Flow_Mods with Packet_Out messages for every
packet, but I experienced the same drops. It seems like OVS starts dropping
packets after some threshold (or buffer overload).


Is there any possibility to debug these drops and maybe to manipulate
ingress buffer sizes (or queue priorities) in order to avoid such drops?

-- 
Best regards,
Anton Matsiuk
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to