Re: [Xen-devel] [PATCH] xen-netback: Turn off the carrier if the guest is not able to receive

From: Zoltan Kiss
Date: Mon Aug 04 2014 - 11:13:26 EST


On 04/08/14 14:35, David Vrabel wrote:
On 30/07/14 20:50, Zoltan Kiss wrote:
Currently when the guest is not able to receive more packets, qdisc layer starts
a timer, and when it goes off, qdisc is started again to deliver a packet again.
This is a very slow way to drain the queues, consumes unnecessary resources and
slows down other guests shutdown.
This patch change the behaviour by turning the carrier off when that timer
fires, so all the packets are freed up which were stucked waiting for that vif.
Instead of the rx_queue_purge bool it uses the VIF_STATUS_RX_PURGE_EVENT bit to
signal the thread that either the timout happened or an RX interrupt arrived, so
the thread can check what it should do. It also disables NAPI, so the guest
can't transmit, but leaves the interrupts on, so it can resurrect.

I don't think you should disable NAPI, particularly since you have to
fiddle with the bits directly instead of usign the API to do so.
Since then I've found a much better way, see xenvif_poll.

I looked at some hardware drivers and none of them disabled NAPI -- they
just allow it to naturally end once hardware queues are drained.

netback is a little different as a frontend could stop processing
to-guest packets but continue sending from-guest ones. I don't see any
problem with allowing this.
Yes, that might be the case. Just a hunch tells me that could be wrong, but I couldn't come up with a scenario to prove it. Let's hear other's opinion about it:
Is it good or bad if a guest interface with carrier off still keeps sending packets towards the backend? Hardware drivers are trusted that when carrier goes down there won't be new packets (apart from a few still in the receive queue of the driver), so NAPI will be automatically descheduled. But in this scenario the guest could still post new packets on the ring, and they will be received unless NAPI is explicitly descheduled.


@@ -1955,24 +1955,78 @@ int xenvif_kthread_guest_rx(void *data)
*/
if (unlikely(queue->vif->disabled && queue->id == 0))
xenvif_carrier_off(queue->vif);
+ else if (unlikely(test_and_clear_bit(QUEUE_STATUS_RX_PURGE_EVENT,
+ &queue->status))) {
+ /* Either the last unsuccesful skb or at least 1 slot
+ * should fit
+ */
+ int needed = queue->rx_last_skb_slots ?
+ queue->rx_last_skb_slots : 1;

- if (kthread_should_stop())
- break;
-
- if (queue->rx_queue_purge) {
+ /* It is assumed that if the guest post new
+ * slots after this, the RX interrupt will set
+ * the bit and wake up the thread again
+ */
+ set_bit(QUEUE_STATUS_RX_STALLED, &queue->status);

This big if needs to go in a new function.

David


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/