All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liu CF/TW" <cfliu.tw@gmail.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath10k/mac80211: add rawtxrx, nohwcrypt module param for raw tx injection, sw crypto support.
Date: Tue, 12 May 2015 16:01:21 -0700	[thread overview]
Message-ID: <CAG5N3qHCRL8m1wJ4xVauK+4rBoLVsPra5Rx5c+5bHUuXPZR8Pg@mail.gmail.com> (raw)
In-Reply-To: <CAG5N3qE6nA2oEhR5Zk8sS331-ycM+jZLBy2BeGPX0ueHqvJ6Kg@mail.gmail.com>

On Tue, May 12, 2015 at 3:44 PM, Liu CF/TW <cfliu.tw@gmail.com> wrote:
> I am going to propose just one single module parameter control: enc_mode
>
> - enc_mode = 0: Use HW crypto (default),
>
>   Driver behavior:
>      - ath10k driver uses native WiFi mode for both Tx/Rx.
>      - ath10k driver configures key to HW.
>      Given HW key descriptor is configured, mac80211 would offload Tx
> encryption to HW and only do Rx decryption (by mac80211) if HW failed
> to do it.
>

Recap. Should be: "Given HW key descriptor is configured, Tx
encryption and Rx decryption would be both done by HW."

Note: Due to HW limitation, SW crypto can't be done in native WiFi mode.
Transmit already encrypted frames requires raw mode.
Bypass encrypted frame for SW for decryption in native Wifi mode is
possible, but requires reinserting QoS header on per frame basis which
is tedious.

>   Use case:
>       - The only mode current driver supports to date.
>       - The CT firmware special use case should fall into this
> category where firmware overrides the ath10k driver setting to force
> Rx fallback to SW decryption (in mac80211).
>          (From Ben's description, I believe CT FW overrides the global
> Rx decap mode=raw mode  + mangle the HW Rx descriptor to skip HW
> decryption)
>
> - enc_mode = 1: Use SW crypto.
>
>   Driver behavior:
>      - ath10k driver uses raw encap mode for both Tx/Rx
>      - ath10k driver doesn't configure actual key to HW but program
> CLEAR key context to bypass HW.
>      This is the classic nohwcrypt=1 mode. Only SW crypto is enabled globally.
>   Use case:
>      - NEW: Full SW crypto on both Tx/Rx.
>      - NEW: raw injected Tx frame. If encryption required, would use
> mac80211 SW crypto.
>
> - enc_mode = 2: Supports both HW and SW crypto simultaneously.
>
>   Driver behavior:
>      - ath10k driver uses raw encap mode for both Tx/Rx
>      - ath10k driver configures key to HW only if the per BSS config
> enables it (either via debugfs or nl80211 attribute, TBD)
>        If HW key is configured, use HW crypto. Otherwise, use SW crypto.
>
>   Use case:
>     - NEW: raw injected Tx frame. If encryption is required, could
> support both SW or HW crypto (by the per BSS config)
>     - NEW: some BSS could use HW crypto with no performance hit while
> some BSS could bypass HW crypto (ex: CAPWAP like split-MAC encrypted
> frames)
>
> Ben, in this case, as long as enc_mode == 0, your FW should continue
> to work. I will add a new FW feature TX_RAW_ENCAP_SUPPORTED, and fail
> at module load time if enc_mode !=0 and FW doesn't support it. Would
> this address your concerns?
>
> David.
>
>

WARNING: multiple messages have this Message-ID (diff)
From: "Liu CF/TW" <cfliu.tw@gmail.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>,
	linux-wireless@vger.kernel.org,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH] ath10k/mac80211: add rawtxrx, nohwcrypt module param for raw tx injection, sw crypto support.
Date: Tue, 12 May 2015 16:01:21 -0700	[thread overview]
Message-ID: <CAG5N3qHCRL8m1wJ4xVauK+4rBoLVsPra5Rx5c+5bHUuXPZR8Pg@mail.gmail.com> (raw)
In-Reply-To: <CAG5N3qE6nA2oEhR5Zk8sS331-ycM+jZLBy2BeGPX0ueHqvJ6Kg@mail.gmail.com>

On Tue, May 12, 2015 at 3:44 PM, Liu CF/TW <cfliu.tw@gmail.com> wrote:
> I am going to propose just one single module parameter control: enc_mode
>
> - enc_mode = 0: Use HW crypto (default),
>
>   Driver behavior:
>      - ath10k driver uses native WiFi mode for both Tx/Rx.
>      - ath10k driver configures key to HW.
>      Given HW key descriptor is configured, mac80211 would offload Tx
> encryption to HW and only do Rx decryption (by mac80211) if HW failed
> to do it.
>

Recap. Should be: "Given HW key descriptor is configured, Tx
encryption and Rx decryption would be both done by HW."

Note: Due to HW limitation, SW crypto can't be done in native WiFi mode.
Transmit already encrypted frames requires raw mode.
Bypass encrypted frame for SW for decryption in native Wifi mode is
possible, but requires reinserting QoS header on per frame basis which
is tedious.

>   Use case:
>       - The only mode current driver supports to date.
>       - The CT firmware special use case should fall into this
> category where firmware overrides the ath10k driver setting to force
> Rx fallback to SW decryption (in mac80211).
>          (From Ben's description, I believe CT FW overrides the global
> Rx decap mode=raw mode  + mangle the HW Rx descriptor to skip HW
> decryption)
>
> - enc_mode = 1: Use SW crypto.
>
>   Driver behavior:
>      - ath10k driver uses raw encap mode for both Tx/Rx
>      - ath10k driver doesn't configure actual key to HW but program
> CLEAR key context to bypass HW.
>      This is the classic nohwcrypt=1 mode. Only SW crypto is enabled globally.
>   Use case:
>      - NEW: Full SW crypto on both Tx/Rx.
>      - NEW: raw injected Tx frame. If encryption required, would use
> mac80211 SW crypto.
>
> - enc_mode = 2: Supports both HW and SW crypto simultaneously.
>
>   Driver behavior:
>      - ath10k driver uses raw encap mode for both Tx/Rx
>      - ath10k driver configures key to HW only if the per BSS config
> enables it (either via debugfs or nl80211 attribute, TBD)
>        If HW key is configured, use HW crypto. Otherwise, use SW crypto.
>
>   Use case:
>     - NEW: raw injected Tx frame. If encryption is required, could
> support both SW or HW crypto (by the per BSS config)
>     - NEW: some BSS could use HW crypto with no performance hit while
> some BSS could bypass HW crypto (ex: CAPWAP like split-MAC encrypted
> frames)
>
> Ben, in this case, as long as enc_mode == 0, your FW should continue
> to work. I will add a new FW feature TX_RAW_ENCAP_SUPPORTED, and fail
> at module load time if enc_mode !=0 and FW doesn't support it. Would
> this address your concerns?
>
> David.
>
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2015-05-12 23:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06  1:06 [PATCH] ath10k/mac80211: add rawtxrx, nohwcrypt module param for raw tx injection, sw crypto support Liu CF/TW
2015-05-06  1:06 ` Liu CF/TW
2015-05-08 11:54 ` Kalle Valo
2015-05-08 11:54   ` Kalle Valo
2015-05-08 16:28   ` Ben Greear
2015-05-08 16:28     ` Ben Greear
2015-05-08 17:35     ` Liu CF/TW
2015-05-08 17:35       ` Liu CF/TW
2015-05-08 17:52       ` Ben Greear
2015-05-08 17:52         ` Ben Greear
2015-05-11 12:12       ` Kalle Valo
2015-05-11 12:12         ` Kalle Valo
2015-05-11 16:17         ` Ben Greear
2015-05-11 16:17           ` Ben Greear
2015-05-12 22:44           ` Liu CF/TW
2015-05-12 22:44             ` Liu CF/TW
2015-05-12 23:01             ` Liu CF/TW [this message]
2015-05-12 23:01               ` Liu CF/TW
2015-05-14 15:12             ` Kalle Valo
2015-05-14 15:12               ` Kalle Valo
2015-05-14 19:35               ` Liu CF/TW
2015-05-14 19:35                 ` Liu CF/TW
2015-05-14 21:16                 ` Ben Greear
2015-05-14 21:16                   ` Ben Greear
2015-05-11 12:24     ` Kalle Valo
2015-05-11 12:24       ` Kalle Valo

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=CAG5N3qHCRL8m1wJ4xVauK+4rBoLVsPra5Rx5c+5bHUuXPZR8Pg@mail.gmail.com \
    --to=cfliu.tw@gmail.com \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=kvalo@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.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.