On Fri, Jan 1, 2021, 1:40 PM Mina Galić wrote:
> On Thursday, December 31st, 2020 at 20:51, Allan Jude <
> allanj...@freebsd.org> wrote:
>
> > We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> >
> > I am wondering if there are any objections to includin
On Thursday, December 31st, 2020 at 20:51, Allan Jude
wrote:
> We've had the AESNI module for quite a few years now, and it has not caused
> any problems.
>
> I am wondering if there are any objections to including it in GENERIC, so
> that users get the benefit without having to have the "trib
On 12/31/20 11:51 AM, Allan Jude wrote:
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
>
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to
On 12/31/20 12:15 PM, Franco Fichtner wrote:
> https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12&id=95b37a4ed741fd116809d0f2cb295c4e9977f5b6
>
> may have subtly broken a number of IPsec installations by stalling active
> connections after certain amounts of traffic transferred. We'
On Thu, 2020-12-31 at 14:09 -0800, Rodney W. Grimes wrote:
> > We've had the AESNI module for quite a few years now, and it has
> > not
> > caused any problems.
> >
> > I am wondering if there are any objections to including it in
> > GENERIC,
> > so that users get the benefit without having to ha
On Thu, Dec 31, 2020 at 3:20 PM Kristof Provost wrote:
> On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote:
> > Its for ever dead code on a large number of machines that do not have
> > the hardware for it. I know that is a decreasing set, but imho it
> > would be better to somehow ONLY load the
On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote:
Its for ever dead code on a large number of machines that do not have
the hardware for it. I know that is a decreasing set, but imho it
would be better to somehow ONLY load the module if you had CPU
support for it. The down side is that detectio
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
>
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPS
On 2020-12-31 11:51, Allan Jude wrote:
We've had the AESNI module for quite a few years now, and it has not
caused any problems.
I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate
: Enabling AESNI by default
We've had the AESNI module for quite a few years now, and it has not
caused any problems.
I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate
https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12&id=95b37a4ed741fd116809d0f2cb295c4e9977f5b6
may have subtly broken a number of IPsec installations by stalling active
connections after certain amounts of traffic transferred. We're still
trying to confirm, but it looks like this ha
On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote:
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
>
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
>
We've had the AESNI module for quite a few years now, and it has not
caused any problems.
I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
yo
13 matches
Mail list logo
