From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgeniy Polyakov Subject: Re: [RFC 1/4] kevent: core files. Date: Tue, 25 Jul 2006 10:26:29 +0400 Message-ID: <20060725062625.GA29242@2ka.mipt.ru> References: <20060709132446.GB29435@2ka.mipt.ru> <20060724.231708.01289489.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org Return-path: Received: from relay.2ka.mipt.ru ([194.85.82.65]:34227 "EHLO 2ka.mipt.ru") by vger.kernel.org with ESMTP id S1751446AbWGYG0m (ORCPT ); Tue, 25 Jul 2006 02:26:42 -0400 To: David Miller Content-Disposition: inline In-Reply-To: <20060724.231708.01289489.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Mon, Jul 24, 2006 at 11:17:08PM -0700, David Miller (davem@davemloft.net) wrote: > From: Evgeniy Polyakov > Date: Sun, 9 Jul 2006 17:24:46 +0400 > > > This patch includes core kevent files: > > - userspace controlling > > - kernelspace interfaces > > - initialisation > > - notification state machines > > > > It might also inlclude parts from other subsystem (like network related > > syscalls so it is possible that it will not compile without other > > patches applied). > > > > Signed-off-by: Evgeniy Polyakov > > I like this work a lot, as I've stated before. The data structures > look like they will scale well and it takes care of all the limitations > that networking in particular seems to have in this area. > > I have to say that the user API is not the nicest in the world. Yet, > at the same time, I cannot think of a better one :) Hi David. I see you have a day of backlog mails processing :) > Please, remove some grot such as this: > > > + if (kevent_cache) > > + k = kmem_cache_alloc(kevent_cache, mask); > > + else > > + k = kzalloc(sizeof(struct kevent), mask); > ... > > + if (kevent_cache) > > + kmem_cache_free(kevent_cache, k); > > + else > > + kfree(k); > > Instead, make this: > > > + kevent_cache = kmem_cache_create("kevent_cache", > > + sizeof(struct kevent), 0, 0, NULL, NULL); > > + if (!kevent_cache) > > + err = -ENOMEM; > > panic(). This is consistent with how other core subsystems handle > SLAB cache creation failures. Ok. > I also think that if we accept this work, it should be first class > citizen with no config options and no ifdefs scattered all over. > Either this is how we do network AIO or it is not. > > I've looked only briefly at Ulrich Drepper's AIO proposal in his OLS > slides, although the DMA bits do not initially strike me as such a hot > idea. I haven't wrapped my brain much around this new stuff, so I'm > not going to touch on it much more just yet. Yes, his idea of dma alloc is extremely good. I manage it with quite big overhead in kevent unfortunately. All other topics are fully covered with kevent (except nice userspace API of course :) ) > The practical advantage kevent has over any new proposal is that 1) > implementation exists :) and 2) several types of test applications and > performance measurements have been made against it which usually > flushes out the worst design issues. I will clean code up and resubmit today. Thank you. -- Evgeniy Polyakov