On Thursday 05 October 2006 16:15, Evgeniy Polyakov wrote: > On Thu, Oct 05, 2006 at 04:01:19PM +0200, Hans Henrik Happe ([EMAIL PROTECTED]) wrote: > > > And what happens when there are 3 empty at the beginning and \we need to > > > put there 4 ready events? > > > > Couldn't there be 3 areas in the mmap buffer: > > > > - Unused: entries that the kernel can alloc from. > > - Alloced: entries alloced by kernel but not yet used by user. Kernel can > > update these if new events requires that. > > - Consumed: entries that the user are processing. > > > > The user takes a set of alloced entries and make them consumed. Then it > > processes the events after which it makes them unused. > > > > If there are no unused entries and the kernel needs some, it has wait for free > > entries. The user has to notify when unused entries becomes available. It > > could set a flag in the mmap'ed area to avoid unnessesary wakeups. > > > > The are some details with indexing and wakeup notification that I have left > > out, but I hope my idea is clear. I could give a more detailed description if > > requested. Also, I'm a user-level programmer so I might not get the whole > > picture. > > This looks good on a picture, but how can you put it into page-based > storage without major and complex shared structures, which should be > properly locked between kernelspace and userspace?
I wasn't clear about the structure. I meant a ring-buffer with 3 areas. So it's basically the same model as Eric Dumazet described, only with 3 indexes; 2 in the user-writeable page and 1 in kernel. When the kernel has alloced an entry it should store it in a way that makes it invalid after user consumsion, which is simply an increment of an index. Sliding-window like schemes should solve this. Hans Henrik Happe - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
