Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 May 2009 05:37:04 +0000 (UTC)
From:      Adrian Chadd <adrian@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r192875 - head/sys/dev/xen/netfront
Message-ID:  <200905270537.n4R5b4Ma084958@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: adrian
Date: Wed May 27 05:37:04 2009
New Revision: 192875
URL: http://svn.freebsd.org/changeset/base/192875

Log:
  Comment tidyup; comment where the next explicit check should
  appear.

Modified:
  head/sys/dev/xen/netfront/netfront.c

Modified: head/sys/dev/xen/netfront/netfront.c
==============================================================================
--- head/sys/dev/xen/netfront/netfront.c	Wed May 27 05:18:13 2009	(r192874)
+++ head/sys/dev/xen/netfront/netfront.c	Wed May 27 05:37:04 2009	(r192875)
@@ -1446,30 +1446,42 @@ xn_start_locked(struct ifnet *ifp) 
 			nfrags++;
 
 		/*
-		 * Don't attempt to queue this packet if there aren't enough free entries in the chain.
-		 * There isn't a 1:1 correspondance between the mbuf TX ring and the xenbus TX ring.
+		 * Don't attempt to queue this packet if there aren't
+		 * enough free entries in the chain.
+		 *
+		 * There isn't a 1:1 correspondance between the mbuf TX ring
+		 * and the xenbus TX ring.
 		 * xn_txeof() may need to be called to free up some slots.
 		 *
-		 * It is quite possible that this can be later eliminated if it turns out that partial
-		 * packets can be pushed into the ringbuffer, with fragments pushed in when further slots
+		 * It is quite possible that this can be later eliminated if
+		 * it turns out that partial * packets can be pushed into
+		 * the ringbuffer, with fragments pushed in when further slots
 		 * free up.
 		 *
-		 * It is also quite possible that the driver will lock up - Xen may not send another
-		 * interrupt to kick the tx/rx processing if the xenbus RX ring is full and xenbus TX ring
-		 * is empty - no further TX work can be done until space is made in the TX mbuf ring and
-		 * the RX side may be waiting for TX data to continue. It is quite possible some timer
-		 * event should be created to kick TX/RX processing along in certain conditions.
+		 * It is also quite possible that the driver will lock up
+		 * if the TX queue fills up with no RX traffic, and
+		 * the mbuf ring is exhausted. The queue may need
+		 * a swift kick to continue.
 		 */
 
-		/* its not +1 like the allocation because we need to keep slot [0] free for the freelist head */
+		/*
+		 * It is not +1 like the allocation because we need to keep
+		 * slot [0] free for the freelist head
+		 */
 		if (sc->xn_cdata.xn_tx_chain_cnt + nfrags >= NET_TX_RING_SIZE) {
 			printf("xn_start_locked: xn_tx_chain_cnt (%d) + nfrags %d >= NET_TX_RING_SIZE (%d); must be full!\n",
-			    (int) sc->xn_cdata.xn_tx_chain_cnt, (int) nfrags, (int) NET_TX_RING_SIZE);
+			    (int) sc->xn_cdata.xn_tx_chain_cnt,
+			    (int) nfrags, (int) NET_TX_RING_SIZE);
 			IF_PREPEND(&ifp->if_snd, m_head);
 			ifp->if_drv_flags |= IFF_DRV_OACTIVE;
 			break;
 		}
 
+		/*
+		 * XXX TODO - make sure there's actually space available
+		 *  in the Xen TX ring for this rather than the hacky way
+		 * its currently done.
+		 */
 
 		/*
 		 * Start packing the mbufs in this chain into



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905270537.n4R5b4Ma084958>