I have a performance critical application that reads packets, both
UDP and Ethernet, from the kernel into user space. When there are
lots of small packets, the program performs relatively poorly....
Recently, while recovering from a really abusive day of snowboarding,
I started thinking about this problem, and I would like to see what
you all think of a potential solution...
Basically, I want a new read method that is something like this:
int mread(int fd, char* buffer, int buffer_size, int* offsets, int offsets_size);
offsets will be an array of integers that the kernel will fill out,
and offsets_size is the length of the array of offsets...
The basic idea is that under heavy load, I expect there to be multiple packets
to be read by the time I get to servicing that file-descriptor. The mread
call could grab multiple packets at once, packing them into the buffer.
User-space code can delineate packets by looking at the offsets. Determining
how many packets were read could be done by looking at the return of mread
(the number of bytes read) and the offsets array. It could also be returned
in another variable if desired....
The kernel knows the max number of packets that can be read based on offsets_size,
as well as buffer limitations due to the size of buffer.
The mread method could be used on UDP and RAW packets at least. It would
be completely worthless for stream-based sockets like TCP...
Comments welcome...
Thanks,
Ben
-- Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:45 EST