Hi,
I've written a patch for skbuff.c & skbuff.h which allows zero-copying of
incoming network frames
from network device drivers by using these new apis.
void init_zero_copy_buffer(zero_copy_header *header,zerocopy_freefunc
freefunc,int order)
init_zero_copy_skb should be called prior to calling make_zero_copy_skb
it's purpose is to initialise the refcnt, the header has to be
at the start of the buffer.
The freefunc is typically kfree & is used to free the buffer up.
struct sk_buff *make_zero_copy_skb(unsigned int size,int gfp_mask,
unsigned char *data,zero_copy_header *zc_header)
make_zero_copy_skb was added so network device drivers could take do
give the network layer data received without memcpying it,
zero_copy_header is used so that drivers can point the refcnt (
skb_datarefp ) to
the head of our allocated buffer rather than the end of the data as used
by alloc_skb
( this would have upset the possibility of being able to use zero copy as
we would
be corrupting the incoming data).
It is the intention that a single refcnt could be used for multiple
zero_copied skbs
which may come from a single larger driver buffer.
The typical usage scenario for this function is as follows
1) receive packet
2) kmalloc new io buffer for io program to replace buffer that just came
in
if this succeeds init_zero_copy_buffer the new buffer & make_zero_copy
skb
the newly received buffer.
3) call netif_rx with the new buffer.
We cant use a static list of circular list of buffers for the io program
& a destructor type concept to free give the buffer back to the driver for
2 reasons.
1) if someone suspends an ftp transfer or similar with ctrl-z
the received buffer will stay in the network stack & not be given
back to the driver until the ftp transfer is unsuspended & thus locking
the driver during this time.
2) if skb->destructor is called when driver is unloaded we would crash
as the function no longer exists, the quantity of code required
to work around this would be 300 or 400 lines as we would have to
pull all the drivers skbuffs from the stack when unregistering the
driver & some of the network code could understandably get upset if we did
this.
For this reason we have kfree_skb_buffer freeing a user specified buffer.
Alan Cox has expressed some intrest in the patches ( in the concept anyway
) & recommended that I post them to you,
I've been using them for a while in my own driver in 2.2.16 & 2.3.99 they
seem relatively stable
under these circumstances anyway. The only case I can think of where they
may not work
is drivers depending on the 16 byte skb_reserve kludge in dev_alloc_skb.
Also a colleague of mine Utz Bacher is coding his gigabit ethernet driver
against these API's.
The patch is against 2.4.0test4 which I have tested & it does run on intel.
Try out the API's if you can find an eligible driver to do so & let me
know.
Hopefully the patch will apply cleanly for you.
Thanks
(See attached file: zero_copy_skb220700.patch)
D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@xxxxxxxxxx,barrow_dj@xxxxxxxxx
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen
zero_copy_skb220700.patch
Description: Binary data
|