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;
MIME-Version: 1.0
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>
In-Reply-To: <20200525105814.GA926693@wp.pl>
From:   Rui Salvaterra <rsalvaterra@gmail.com>
Date:   Mon, 25 May 2020 12:14:54 +0100
Message-ID: <CALjTZvY0qPXxS=VPG3Ma6CCdtWo2g2XC3Cnks6jnNSFzqz-HAQ@mail.gmail.com>
Subject: Re: [RFC PATCH] rt2800lib: unconditionally enable MFP
To:     Stanislaw Gruszka <stf_xl@wp.pl>
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
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi, Stanislaw,

On Mon, 25 May 2020 at 11:58, Stanislaw Gruszka <stf_xl@wp.pl> wrote:
>
> Yeah, and at least without nohwcrypt=y we can still use HW encryption
> for non-MFP stations.
>
> Rui, feel free to repost your patch with additional sta->mfp check.

Sure, will do. :)

> 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). 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.

Rui