[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8E97A6A3-2B8D-4E03-960B-8625DA3BA4FF@gmail.com>
Date: Thu, 27 Jun 2019 19:31:26 -0700
From: "Jonathan Lemon" <jonathan.lemon@...il.com>
To: "Jakub Kicinski" <jakub.kicinski@...ronome.com>
Cc: netdev@...r.kernel.org, bjorn.topel@...el.com,
magnus.karlsson@...el.com, saeedm@...lanox.com,
maximmi@...lanox.com, brouer@...hat.com, kernel-team@...com
Subject: Re: [PATCH 2/6 bpf-next] Clean up xsk reuseq API
On 27 Jun 2019, at 15:38, Jakub Kicinski wrote:
> On Thu, 27 Jun 2019 15:08:32 -0700, Jonathan Lemon wrote:
>> The reuseq is actually a recycle stack, only accessed from the kernel
>> side.
>> Also, the implementation details of the stack should belong to the
>> umem
>> object, and not exposed to the caller.
>>
>> Clean up and rename for consistency in preparation for the next
>> patch.
>>
>> Signed-off-by: Jonathan Lemon <jonathan.lemon@...il.com>
>
> Prepare/swap is to cater to how drivers should be written - being able
> to allocate resources independently of those currently used. Allowing
> for changing ring sizes and counts on the fly. This patch makes it
> harder to write drivers in the way we are encouraging people to.
>
> IOW no, please don't do this.
The main reason I rewrote this was to provide the same type
of functionality as realloc() - no need to allocate/initialize a new
array if the old one would still end up being used. This would seem
to be a win for the typical case of having the interface go up/down.
Perhaps I should have named the function differently?
--
Jonathan
Powered by blists - more mailing lists