[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55B93611.7070506@ti.com>
Date: Wed, 29 Jul 2015 16:22:41 -0400
From: Murali Karicheri <m-karicheri2@...com>
To: Eric Dumazet <eric.dumazet@...il.com>,
WingMan Kwok <w-kwok2@...com>
CC: <davem@...emloft.net>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] net: Export __netdev_alloc_frag() to allow gfp_mask
flags
Eric,
On 07/29/2015 12:31 PM, Eric Dumazet wrote:
> On Wed, 2015-07-29 at 11:10 -0400, WingMan Kwok wrote:
>> This patch makes the function __netdev_alloc_frag() non-static and
>> exports it so that drivers that need to specify additional flags,
>> such as __GFP_DMA, can use it. The currently exported function,
>> netdev_alloc_frag() doesn't allow passing in gfp_mask flags.
>>
>> Signed-off-by: WingMan Kwok <w-kwok2@...com>
>> Signed-off-by: Reece R. Pollack <x0183204@...com>
>> ---
>> include/linux/skbuff.h | 1 +
>> net/core/skbuff.c | 3 ++-
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> You can not do this.
>
> __napi_alloc_frag() uses __alloc_page_frag() using a per cpu reserve.
>
Thanks for your response.
I assume you mean to say __netdev_alloc_frag() which is what the patch
affects. Right?
> This per cpu reserve would be shared by regular GFP_ATOMIC and your
> __GFP_DMA allocations.
I am trying to understand the issue here. Is there any issue in sharing
this per CPU reserve between DMA and ATOMIC allocations. Without this
flag, the assumption is this function can return memory which is not
DMA-able and this flag assures it is allocated from DMA zone.
Murali
>
>
>
>
>
--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists