Author: adrian
Date: Fri Jun 12 04:19:03 2020
New Revision: 362084
URL: https://svnweb.freebsd.org/changeset/base/362084

Log:
  [net80211] First part of A-MSDU offload handling - don't bump A-MPDU 
reordering seqno
  
  When doing A-MSDU offload handling the driver is required to mark
  A-MSDUs from the same MPDU with the same sequence number.
  It then tags them as AMSDU (if it's a decap'ed A-MSDU) and AMSDU_MORE
  (saying there's more AMSDUs decapped in the same MSDU.)
  This allows encryption and sequence number offload to work right.
  
  In the A-MSDU path the sequence number check looks at the A-MSDU flags
  in the frame to see whether it's part of the same seqno and will pass them
  (ie, not increment rx_seq until the last A-MSDU is seen from the driver,
  or a new seqno shows up.0
  
  However, I did this work in the A-MSDU path but not the A-MSDU in A-MPDU path.
  For the non A-MDSU offload case the A-MPDU receive reordering will do its
  thing and then pass up the MPDU up for decap - which then will see it's
  an A-MSDU and decap each sub-frame.  But this isn't done for offloaded
  A-MSDU frames.
  
  This requires two parts:
  
  * Don't bump the RX sequence number, same as above; and
  * If frames go into the reordering buffer, they need to be added into the slot
    as a set of frames rather than a single frame, so once a new seqno shows up
    this slot can be marked as "full" and we can move on.
  
  This patch does the first.  The latter requires that I find and commit
  work to change rxa_m from an mbuf to an mbufq and the nhandle A-MSDU
  there.  But, the first is enough to allow the normal case (ie, no or not
  a lot of A-MPDU RX reordering) to work.
  
  This allows the athp driver (QCA9880) throughput to go from VERY low
  (like 5mbit TCP, 1/3-1/4 expected UDP throughput) to ~ 250mbit TCP
  and > 300mbit UDP on a VHT/40 channel.  TCP sucks because, well, it
  shows up as MASSIVE packet loss when all but one frame in a decap'ed
  A-MSDU stream is dropped. Le whoops.
  
  Now, where'd I put that laptop with the patch for rxa_m mbufq that
  I wrote like in 2017...
  
  Tested:
  
  * AR9380, STA/AP mode (a big no-op, no A-MSDU hardware decap);
  * if_run (RT3593), STA DWDS mode (A-MPDU / A-MSDU receive, but again
    no A-MSDU hardware decap);
  * QCA9880, STA/AP mode (which is doing hardware A-MPDU/A-MSDU decap,
    but no A-MPDU reordering in the firmware.)

Modified:
  head/sys/net80211/ieee80211_ht.c

Modified: head/sys/net80211/ieee80211_ht.c
==============================================================================
--- head/sys/net80211/ieee80211_ht.c    Fri Jun 12 01:58:14 2020        
(r362083)
+++ head/sys/net80211/ieee80211_ht.c    Fri Jun 12 04:19:03 2020        
(r362084)
@@ -875,6 +875,7 @@ ieee80211_ampdu_reorder(struct ieee80211_node *ni, str
        ieee80211_seq rxseq;
        uint8_t tid;
        int off;
+       int amsdu_more = ieee80211_check_rxseq_amsdu_more(rxs);
 
        KASSERT((m->m_flags & (M_AMPDU | M_AMPDU_MPDU)) == M_AMPDU,
            ("!a-mpdu or already re-ordered, flags 0x%x", m->m_flags));
@@ -949,10 +950,11 @@ again:
                        return CONSUMED;
                } else {
                        /*
-                        * In order; advance window and notify
+                        * In order; advance window if needed and notify
                         * caller to dispatch directly.
                         */
-                       rap->rxa_start = IEEE80211_SEQ_INC(rxseq);
+                       if (amsdu_more)
+                               rap->rxa_start = IEEE80211_SEQ_INC(rxseq);
                        return PROCESS;
                }
        }
@@ -996,7 +998,8 @@ again:
                                            rap->rxa_qframes;
                                        ampdu_rx_flush(ni, rap);
                                }
-                               rap->rxa_start = IEEE80211_SEQ_INC(rxseq);
+                               if (amsdu_more)
+                                       rap->rxa_start = 
IEEE80211_SEQ_INC(rxseq);
                                return PROCESS;
                        }
                } else {
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to