Several cheap busmaster nics only accept tx buffers that are 32-bit Currently they memcpy into transfer buffers. What about replacing that memcpy with csum_copy_partial_nocheck and enabling NETIF_F_{
I'm definitely for reducing copies, so this patch looks nice. I would prefer to call it "single-copy" or something other than zero-copy, though... -- Jeff Garzik | Andre the Giant has a posse. Buildi
I'm going to assume that it is safe to bet that such cards cannot take multiple buffers for a TX packet too. Because if they could, then we could do something like copy the header forward a few bytes
Incorrect assumption. If it were that easy, don't you think the device driver writer would have used the same technique to avoid the bulk copy? There wouldn't be an alignment requirement if it were n
skb_copy_datagram & friends follow the fragment list. My function doesn't/mustn't follow skb_shinfo(skb)->frag_list. Should I still call it skb_copy_datagram{,_iovec}_kernel? I don't like functions w
Why "mustn't it" follow the frag list? I think it would be "absolutely fantastic" if it did follow the frag list! Then we could optimize the forwarding of fragmented packets. There is no subtle diffe
^^^^^^^^^^^^ It's an improvement for the tx codepath: If an application uses sendfile with an 8139too [or via-rhine,...] nic then currently 2 copies are made: 1) copy_and_csum into skb->data 2) memco
Several cheap busmaster nics only accept tx buffers that are 32-bit aligned. Currently they memcpy into transfer buffers. What about replacing that memcpy with csum_copy_partial_nocheck and enabling
I'm definitely for reducing copies, so this patch looks nice. I would prefer to call it "single-copy" or something other than zero-copy, though... -- Jeff Garzik | Andre the Giant has a posse. Buildi
I'm going to assume that it is safe to bet that such cards cannot take multiple buffers for a TX packet too. Because if they could, then we could do something like copy the header forward a few bytes
Incorrect assumption. If it were that easy, don't you think the device driver writer would have used the same technique to avoid the bulk copy? There wouldn't be an alignment requirement if it were n
skb_copy_datagram & friends follow the fragment list. My function doesn't/mustn't follow skb_shinfo(skb)->frag_list. Should I still call it skb_copy_datagram{,_iovec}_kernel? I don't like functions w
Why "mustn't it" follow the frag list? I think it would be "absolutely fantastic" if it did follow the frag list! Then we could optimize the forwarding of fragmented packets. There is no subtle diffe
^^^^^^^^^^^^ It's an improvement for the tx codepath: If an application uses sendfile with an 8139too [or via-rhine,...] nic then currently 2 copies are made: 1) copy_and_csum into skb->data 2) memco