On Tue, Aug 23, 2016 at 04:14:44PM +0200, Maxime Coquelin wrote:
> > /* Specify timeout (in useconds) between retries on RX. */
> > static uint32_t burst_rx_delay_time = BURST_RX_WAIT_US;
> >@@ -297,6 +298,17 @@ port_init(uint8_t port)
> >
> > rx_ring_size = RTE_TEST_RX_DESC_DEFAULT;
> > tx_ring_size = RTE_TEST_TX_DESC_DEFAULT;
> >+
> >+ /*
> >+ * When Tx zero copy is enabled, guest Tx used vring will be updated
> >+ * only when corresponding mbuf is freed. Thus, the nb_tx_desc
> >+ * (tx_ring_size here) must be small enough so that the driver will
> >+ * hit the free threshold easily and free mbufs timely. Otherwise,
> >+ * guest Tx vring would be starved.
> >+ */
> >+ if (tx_zero_copy)
> >+ tx_ring_size = 64;
>
> I have a concern about more complex applications, where the mbufs might
> not be consumed sequentially.
> If one mbuf gets stuck for a while, whereas all others are consumed,
> we would face starvation.
I guess that exactly belongs to the worst case I mentioned in another
email. That's why I think we should not break the loop when a head
mbuf is not consumed.
--yliu
> For example, the packet is to be routed to a VM, which is paused,
> and the routing thread keeps retrying to enqueue the packet for a while.
>
> Anyway, this feature is optional and off by default, so having the
> feature applied is not a blocker.
>
> Thanks!
> Maxime
