From: Stanislaw Gruszka <stf_xl@wp.pl>
To: Rui Salvaterra <rsalvaterra@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Julian Calaby <julian.calaby@gmail.com>,
Kalle Valo <kvalo@codeaurora.org>,
Larry Finger <Larry.Finger@lwfinger.net>,
linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH] rt2800lib: unconditionally enable MFP
Date: Mon, 25 May 2020 14:25:35 +0200 [thread overview]
Message-ID: <20200525122535.GA927343@wp.pl> (raw)
In-Reply-To: <CALjTZvY0qPXxS=VPG3Ma6CCdtWo2g2XC3Cnks6jnNSFzqz-HAQ@mail.gmail.com>
Hello
On Mon, May 25, 2020 at 12:14:54PM +0100, Rui Salvaterra wrote:
> > If someone is willing to implement mt76 approach to have HW encryption offload
> > for MFP+CCMP, I'll be happy to review patch. From other hand, most people will
> > use MFP with modern ciphers anyway, so I'm not sure how much need is for such
> > patch.
>
> I've been having a look at how mt76 solves the problem, but I haven't
> fully understood it yet. I feel it's out of my league, since I only
> started looking at wireless drivers very recently (I don't grasp all
> the concepts and the architecture).
Yeah, it's somewhat complicated.
> But one thing that also bugs me
> about software fallbacks is that for most of the older CPUs we don't
> have SIMD implementations of the required crypto. So, not only we fall
> back to software, but we're also stuck with scalar C algorithms on
> CPUs which are already slow.
If we talk about x86, we have AES-NI instructions since 2008:
https://en.wikipedia.org/wiki/AES_instruction_set
Which make CPU crypto quite fast. Though it can be a bottleneck,
I think, if wifi encryption is performed together with other encryption
applications like SSL .
Stanislaw
next prev parent reply other threads:[~2020-05-25 12:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-24 9:47 [RFC PATCH] rt2800lib: unconditionally enable MFP Rui Salvaterra
2020-05-24 11:17 ` Stanislaw Gruszka
2020-05-24 11:42 ` Julian Calaby
2020-05-24 12:39 ` Stanislaw Gruszka
2020-05-25 9:15 ` Johannes Berg
2020-05-25 9:31 ` Stanislaw Gruszka
2020-05-25 9:49 ` Johannes Berg
2020-05-25 10:58 ` Stanislaw Gruszka
2020-05-25 11:14 ` Rui Salvaterra
2020-05-25 12:25 ` Stanislaw Gruszka [this message]
2020-05-25 12:33 ` Rui Salvaterra
2020-05-25 13:13 ` Rui Salvaterra
2020-05-25 13:14 ` Johannes Berg
2020-05-25 13:28 ` Rui Salvaterra
2020-05-24 15:07 ` Rui Salvaterra
2020-05-25 0:02 ` Larry Finger
2020-05-25 9:17 ` Johannes Berg
2020-05-25 8:17 ` Stanislaw Gruszka
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=20200525122535.GA927343@wp.pl \
--to=stf_xl@wp.pl \
--cc=Larry.Finger@lwfinger.net \
--cc=johannes@sipsolutions.net \
--cc=julian.calaby@gmail.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rsalvaterra@gmail.com \
/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.