Error in dmesg --> "bess - free_snb_bulk():155 vport0: RX free queue overflow!"

[netsys]

Error in dmesg --> "bess - free_snb_bulk():155 vport0: RX free queue overflow!"

[chaitanyalala]

Seems the error comes from -->

static inline int __attribute__((always_inline)) 
__llring_sp_do_enqueue(struct llring *r, void * const *obj_table, 
                         unsigned n, enum llring_queue_behavior behavior) 
{ 
        uint32_t prod_head, cons_tail;  
        uint32_t prod_next, free_entries; 
        unsigned i; 
        uint32_t mask = r->common.mask;                                                     
        int ret;                                                                            

        prod_head = r->prod.head; 
        cons_tail = r->cons.tail; 
        /* The subtraction is done between two unsigned 32bits value 
         * (the result is always modulo 32 bits even if we have 
         * prod_head > cons_tail). So 'free_entries' is always between 0 
         * and slots(ring)-1. */                                                            
        free_entries = mask + cons_tail - prod_head;                                        

        /* check that we have enough room in ring */ 
        if (llring_unlikely(n > free_entries)) { 
                if (behavior == LLRING_QUEUE_FIXED) { 
                        __RING_STAT_ADD(r, enq_fail, n); 
                        return -LLRING_ERR_NOBUF; 
                } 

[chaitanyalala]

By adding some instrumentation it seems that when it fails "n" is 32. Not sure that it helps.

[sangjinhan]

Yes, as you rightly pointed out, it is caused when the producer (kernel driver) overwhelms the consumer (bessd). Normally this should happen very rarely, since the BESS daemon runs much faster than the kernel side in general. However, if the CPU on which the bessd worker thread is running switches to another thread, the queue will be only enqueued but never drained for the duration.

Whenever the overflow happens, some BESS packets will be "lost", eventually exhausting the packet buffer pool.

The ring for the driver -> bess direction has capacity of N packets, but the problem was there can be at most N + 32 packets that can be enqueued. I pushed a patch that limits the number of on-the-fly packets so that the driver -> bess ring does never overflow.