[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCHv1] xen-netfront: always keep the Rx ring full of requests
On 2014/10/7 5:43, David Vrabel wrote:
On 06/10/14 22:07, David Miller wrote:
From: annie li <annie.li@xxxxxxxxxx>
Date: Mon, 06 Oct 2014 14:41:48 -0400
On 2014/10/6 12:00, David Vrabel wrote:
+ queue->rx.req_prod_pvt = req_prod;
+
+ /* Not enough requests? Try again later. */
+ if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+ mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
+ return;
If the previous for loop breaks because of failure of
xennet_alloc_one_rx_buffer, then notify_remote_via_irq is missed here
if
the code returns directly.
This is deliberate -- there's no point notifying the backend if there
aren't enough requests for the next packet. Since we don't know what
the next packet might be we assume it's the largest possible.
That makes sense.
However, the largest packet case does not happen so
frequently. Moreover, netback checks the slots every incoming skb
requires in xenvif_rx_ring_slots_available, not only concerning the
largest case.
An upcoming change to netback will cause it to wait for enough slots for
the largest possible packet.
Netback knows the exact slot number that incoming skb will consumes, is
there any reason to let it wait for the largest possible packets?
Thanks
Annie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
