lkml.org 
[lkml]   [2001]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1
Date
>> struct kiovec2 {
>> int nbufs; /* Kiobufs actually referenced */
>> int array_len; /* Space in the allocated lists */
>> struct kiobuf * bufs;
>
> Any reason for array_len?
>
> Why not just
>
> int nbufs,
> struct kiobuf *bufs;
>
> Remember: simplicity is a virtue.
>
> Simplicity is also what makes it usable for people who do NOT want to have
> huge overhead.
>
>> unsigned int locked : 1; /* If set, pages has been locked */
>
> Remove this. I don't think it's valid to lock the pages. Who wants to use
> this anyway?
>
>> /* Always embed enough struct pages for 64k of IO */
>> struct kiobuf * buf_array[KIO_STATIC_PAGES];
>
> Kill kill kill kill.
>
> If somebody wants to embed a kiovec into their own data structure, THEY
> can decide to add their own buffers etc. A fundamental data structure
> should _never_ make assumptions like this.

What about getting rid of both that and the pointer, and just
hanging that data on the end as a variable length array?

struct kiovec2{
int nbufs;
/* ... */
struct kiobuf[0];
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:26    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog