[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJdmCrKTg89nv0XKSHW8atHfQu-cKe_Dg7Kpv8bYyO38H2oNJQ@mail.gmail.com>
Date: Thu, 23 Oct 2014 17:46:06 +0300
From: Crestez Dan Leonard <cdleonard@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>,
Jonathan Toppins <jtoppins@...ulusnetworks.com>
Cc: David Ahern <dsahern@...il.com>, netdev@...r.kernel.org
Subject: Re: [RFC] tcp md5 use of alloc_percpu
On Thu, Oct 23, 2014 at 4:21 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Thu, 2014-10-23 at 02:58 -0400, Jonathan Toppins wrote:
>
>> > + if (!pool) {
>> > + pool = kzalloc_node(sizeof(*pool), GFP_KERNEL,
>> GFP_DMA | GFP_KERNEL
>> This memory will possibly be used in a DMA correct? (thinking crypto
>> hardware offload)
>
> I am not sure this is the case, but this certainly can be added.
As far as I know what GFP_DMA actually does is restrict allocation to
low memory addresses under 24 bits for very old devices. There is also
GFP_DMA32 which restricts to addresses under 32 bytes (for device
which don't support 64 bit addresses).
This kind of stuff only belongs in device drivers where the exact
hardware limitations are known. I don't think crypto devices with this
kind of limitations can be exposed through the crypto API that the
md5sig feature uses.
--
Regards,
Leonard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists