On Fri, Jul 31, 2015 at 09:38:17AM +0530, Abhishek Verma wrote: > > > > > > > > I just see *4424 *packets getting lost. What are these packets? Any idea > > > when would we lose them? > > > > "lost" means that a queue from the kernel to userspace overflowed. It > > would ordinarily happen if there was a big burst of packets that didn't > > match in the kernel flow table. > > > > But this wouldnt ever happen if i have an explicit flow-rule added that > says, for example, that all packets with a certain IP address coming on a > certain OVS port must go out on a certain OVS port. In that case i already > have a flow programmed before the packets started arriving. That way i can > at least rule out the packet drops because of the reason you cited above. > > 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. 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. > 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 [email protected] http://openvswitch.org/mailman/listinfo/discuss
