ath: bump the default node queue size to 128 frames, not 64

It turns out that, silly adrian, setting it to 64 means only two
AMPDU frames of 32 subframes each.  Thus, whilst those are in-flight,
any subsequent queues frames to that node get dropped.

This ends up being pretty no bueno for performance if any receive
is also going on at that point.

Instead, set it to 128 for the time being to ensure that SOME
frames get queued in the meantime.  This results in some frames
being immediately available in the software queue for transmit
when the two existing A-MPDU frames have been completely sent,
rather than the queue remaining empty until at least one is sent.

It's not the best solution - I still think I'm scheduling receive
far more often than giving time to schedule transmit work -
but at least now I'm not starving the transmit side.

Before this, a bidirectional iperf would show receive at ~ 150mbit/sec.
but the transmit side at like 10kbit/sec.  With it set to 128 it's
now 150mbit/sec receive, and ~ 10mbit receive.  It's better than 10kbit/sec,
but still not as far as I'd like it to be.

Tested:

* AR9380/QCA934x (TL-WDR4300 AP), Macbook pro test STA + AR9380 test STA

sys/dev/ath/if_ath.c

@@ -1083,9 +1083,16 @@ ath_attach(u_int16_t devid, struct ath_softc *sc)
 
 	/*
 	 * Default the maximum queue to 1/4'th the TX buffers, or
-	 * 64, whichever is smaller.
+	 * 128, whichever is smaller.
+	 *
+	 * Set it to 128 instead of the previous default (64) because
+	 * at 64, two full A-MPDU subframes of 32 frames each is
+	 * enough to treat this node queue as full and all subsequent
+	 * traffic is dropped. Setting it to 128 means there'll
+	 * hopefully be another 64 frames in the software queue
+	 * to begin making A-MPDU frames out of.
 	 */
-	sc->sc_txq_node_maxdepth = MIN(64, ath_txbuf / 4);
+	sc->sc_txq_node_maxdepth = MIN(128, ath_txbuf / 4);
 
 	/* Enable CABQ by default */
 	sc->sc_cabq_enable = 1;