All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
	Manikanta Pubbisetty <mpubbise@codeaurora.org>
Subject: Re: [PATCH v2 1/2] ath11k: handle RX fragments
Date: Tue, 17 Mar 2020 06:36:20 +0000 (UTC)	[thread overview]
Message-ID: <20200317063620.AFA2FC432C2@smtp.codeaurora.org> (raw)
In-Reply-To: <1584088343-3584-2-git-send-email-mpubbise@codeaurora.org>

Manikanta Pubbisetty <mpubbise@codeaurora.org> wrote:

> IPQ8074 HW has support to verify the PN of the received frames.
> For all frames except for fragmented ones, HW checks the PN and
> delivers them to the driver. For fragmented frames, driver is
> required to do a little more; it has to reassemble the fragments
> and then reinject them to the HW for verifying the PN. Currently,
> to keep the logic simple, PN verifcation is disabled in HW and is
> handled in mac80211 for all the frames (fragmented and unfragmented).
> 
> On the contrary, offloading PN Validation to the HW brings important
> benefits. It reduces CPU cycles spent on the host CPU for verifying
> the same; helps in enabling features which improve performance like
> mac80211 fast RX path, enabling multiple REO rings for parallel RX
> processing, 802.11 decapsulation offloading. All these features are
> dependent on PN offload which in turn is dependent on handling of
> the received fragments in the driver.
> 
> When TKIP security is used, additional handling is required while
> processing the fragments; since MIC is computed on an MSDU in TKIP,
> only the last fragment has the MIC info. In this case, driver has to
> compute the MIC after reassembly and compare it against the MIC
> present in the frame. For this, MICHAEL_MIC kernel crypto library
> APIs are used and the dependencies are appropriately set.
> 
> Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

2 patches applied to ath-next branch of ath.git, thanks.

243874c64c81 ath11k: handle RX fragments
1441b2f205a7 ath11k: enable PN offload

-- 
https://patchwork.kernel.org/patch/11436249/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  parent reply	other threads:[~2020-03-17  6:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13  8:32 [PATCH v2 0/2] ath11k: offload PN verification to the HW Manikanta Pubbisetty
2020-03-13  8:32 ` Manikanta Pubbisetty
2020-03-13  8:32 ` [PATCH v2 1/2] ath11k: handle RX fragments Manikanta Pubbisetty
2020-03-13  8:32   ` Manikanta Pubbisetty
2020-03-17  6:36   ` Kalle Valo
2020-03-17  6:36   ` Kalle Valo [this message]
2020-03-13  8:32 ` [PATCH v2 2/2] ath11k: enable PN offload Manikanta Pubbisetty
2020-03-13  8:32   ` Manikanta Pubbisetty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200317063620.AFA2FC432C2@smtp.codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=ath11k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mpubbise@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.