Hi hopefully this will clarify a few open questions,
>>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.
>I'm uncertain of which skb_reserve() you are referring to, but
skb_reserve()
>is often used for performance reasons. For instance, the drivers use
>skb_reserve(skb, 2) to longword- and cache-align the IP header. In some
cases
>the skbuff data section is offset to allow the chip to linearly write the
Rx
>status before the packet data in one PCI transaction. With careful driver
>construction each receive packet can be transferred in a single PCI burst
>instead of four or more transactions that would otherwise be needed.
Wrt the skb_reserve kludge this is what I was referring to.
static inline struct sk_buff *dev_alloc_skb(unsigned int length)
{ struct sk_buff *skb;
skb = alloc_skb(length+16, GFP_ATOMIC); /* Kludge inserted here :-)
*/
if (skb)
skb_reserve(skb,16);
return skb;
}
I'm getting tons of recommendations to join a linux-fastio mailing list, I
think I'm on enough of the things.
I'll call the functions one_less_copy_skb if it makes people happier.
The fact remains that because we S/390 network interfaces give us multiple
network frames in one read buffer
We don't even know how many network frames we will receive until we get
the buffer from the cards.
We can't allocate our single skb beforehand & point the card at the buffer.
In short whatever wonderful things are being done with kiobuffs for 2.5 we
have to continue our memcpying
into post allocated skb's unless we have a mechanism of converting a single
large buffer into multiple skbs
in an arbitrary fashion & giving it to the upper network layers as done in
the code I posted.
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
|