Hi Flavio,
> > Is this correct? > > No, there is a cache in the kernel which is periodically refreshed or > empty at the initialization. When the first packet comes in the > packet is queued to the userspace daemon which will update the > kernel's cache. Next packets matching the cached flow will pass > directly. > Aha. So, the of-ctl add-flow really adds a flow only in the User Space and nothing in the kernel space. If this flow rule isnt added then all packets will hit the default rule where we do normal L2 learning and switching. By adding of-ctl add-flow rules we simply over-ride that behavior. The real flows that get added by the user space daemon that the packets actually hit can be viewed by "ovs-dpctl dump-flows". Is this how it is? > However, depending on how you programmed your flows and the traffic, > you could see a burst coming for a flow that isn't cached yet. Since > the queue is limited, it can overflow. > Ok, and these drops are visible when i give "ovs-dpctl show" command. Is there a way to increase this queue size? Flows afaik are always timed out after 5 secs. Assume i have an application that bursts every 6 secs. In that case i always run the risk of losing packets. Is there a way to pin a flow or increase its timeout value? Thanks, Abhishek > > > Packets can also be lost this way if OVS is stopped and restarted. > > > > > > Since this is a GRE tunnel, packets can get lost in the kernel TCP/IP > > > stack GRE processing on ingress or egress, and that wouldn't show up in > > > any of these places. > > > > > > > Do you know if there are any stats that i could look at in the Linux > kernel > > that will give me these stats? > > netstat -s/dropwatch > > fbl > >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
