From owner-svn-src-head@freebsd.org Fri Jun 12 04:19:03 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D399F32D3B8; Fri, 12 Jun 2020 04:19:03 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jnY354nxz3clF; Fri, 12 Jun 2020 04:19:03 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A9A9423C01; Fri, 12 Jun 2020 04:19:03 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 05C4J3RT033307; Fri, 12 Jun 2020 04:19:03 GMT (envelope-from adrian@FreeBSD.org) Received: (from adrian@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 05C4J349033306; Fri, 12 Jun 2020 04:19:03 GMT (envelope-from adrian@FreeBSD.org) Message-Id: <202006120419.05C4J349033306@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: adrian set sender to adrian@FreeBSD.org using -f From: Adrian Chadd Date: Fri, 12 Jun 2020 04:19:03 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r362084 - head/sys/net80211 X-SVN-Group: head X-SVN-Commit-Author: adrian X-SVN-Commit-Paths: head/sys/net80211 X-SVN-Commit-Revision: 362084 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 04:19:03 -0000 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 {