Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 25 May 2020 14:25:35 +0200
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
Message-ID: <20200525122535.GA927343@wp.pl>
References: <20200524094730.2684-1-rsalvaterra@gmail.com>
 <20200524111751.GA914918@wp.pl>
 <CAGRGNgWuQjQzDS9-cPAx7TnDfEiGnSccw4vqPAE_gWV=QS5JVw@mail.gmail.com>
 <20200524123931.GA915983@wp.pl>
 <640c254edb9fdaec2fd8987d1f2d345bd1d9276c.camel@sipsolutions.net>
 <20200525093142.GA926004@wp.pl>
 <9a8da74898b68fb63f65567068de0fcb2b5a57b0.camel@sipsolutions.net>
 <20200525105814.GA926693@wp.pl>
 <CALjTZvY0qPXxS=VPG3Ma6CCdtWo2g2XC3Cnks6jnNSFzqz-HAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALjTZvY0qPXxS=VPG3Ma6CCdtWo2g2XC3Cnks6jnNSFzqz-HAQ@mail.gmail.com>
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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