Re: [Linux-ATM-General] Do skbuffs passed to dev->ops->send() have tailroom?

[Mike W. <we...@cs...>]

While 'tis true that the skb's come from the size-NNN caches,  the 
"extra space"
will not be reflected in the header -- so virtually all of the time you 
will do a
copy_expand().  The value of "size" at this point includes MAC+IP+TRANSPORT
headroom and the length of the "user" data component of the packet.

If this driver is for "limited distribution (e.g. your own shop...) you 
could just
add in the tailroom here and build a new kernel!    

187 <http://lxr.linux.no/source/net/core/skbuff.c#L187>         *//* Get the DATA. Size must match skb_add_mtu(). *//*
188 <http://lxr.linux.no/source/net/core/skbuff.c#L188>         size <http://lxr.linux.no/ident?i=size> = SKB_DATA_ALIGN <http://lxr.linux.no/ident?i=SKB_DATA_ALIGN>(size <http://lxr.linux.no/ident?i=size>);
189 <http://lxr.linux.no/source/net/core/skbuff.c#L189>         data <http://lxr.linux.no/ident?i=data> = kmalloc <http://lxr.linux.no/ident?i=kmalloc>(size <http://lxr.linux.no/ident?i=size> + sizeof(struct skb_shared_info <http://lxr.linux.no/ident?i=skb_shared_info>), gfp_mask);
190 <http://lxr.linux.no/source/net/core/skbuff.c#L190>         if (data <http://lxr.linux.no/ident?i=data> == NULL <http://lxr.linux.no/ident?i=NULL>)
191 <http://lxr.linux.no/source/net/core/skbuff.c#L191>                 goto nodata;
192 <http://lxr.linux.no/source/net/core/skbuff.c#L192> 
193 <http://lxr.linux.no/source/net/core/skbuff.c#L193>         *//* XXX: does not include slab overhead *//* 
194 <http://lxr.linux.no/source/net/core/skbuff.c#L194>         skb->truesize = size <http://lxr.linux.no/ident?i=size> + sizeof(struct sk_buff <http://lxr.linux.no/ident?i=sk_buff>);
195 <http://lxr.linux.no/source/net/core/skbuff.c#L195> 
196 <http://lxr.linux.no/source/net/core/skbuff.c#L196>         *//* Load the data pointers. *//*
197 <http://lxr.linux.no/source/net/core/skbuff.c#L197>         skb->head <http://lxr.linux.no/ident?i=head> = data <http://lxr.linux.no/ident?i=data>;
198 <http://lxr.linux.no/source/net/core/skbuff.c#L198>         skb->data <http://lxr.linux.no/ident?i=data> = data <http://lxr.linux.no/ident?i=data>;
199 <http://lxr.linux.no/source/net/core/skbuff.c#L199>         skb->tail <http://lxr.linux.no/ident?i=tail> = data <http://lxr.linux.no/ident?i=data>;
200 <http://lxr.linux.no/source/net/core/skbuff.c#L200>         skb->end <http://lxr.linux.no/ident?i=end> = data <http://lxr.linux.no/ident?i=data> + size <http://lxr.linux.no/ident?i=size>;


It also <<might>> be the case that the remainder of the block (up to the 
next power
of 2) is safe for use.  In which case your driver might be able to save the
skb_shared_info structure somewhere while the packet was being Tx'ed and 
use
that space (36 bytes) plus leftover space in the power of two block.

If you do that though you must put the skb_shared_info structure back before
freeing the skb.  



Alex Zeffertt wrote:

>On Wed, 2003-04-16 at 18:08, chas williams wrote:
>  
>
>>>I could kmalloc enough memory for the PDU and memcpy the skbuff to it,
>>>but it would be much more efficient to just append some padding and a
>>>trailer to the skbuff, and pass the pointer directly to the h/w.  The
>>>problem with this is that I don't know whether the skbuffs will always
>>>have enough tailroom to allow this.
>>>      
>>>
>>skb's will not always have enough room for a trailer.  you might need
>>to make copy (skb_copy_expand() could be used for this) to get enough
>>trailer/header.  check skb_tailroom() first though.  i believe skb's
>>come from a pool of fixed sizes (look at /proc/slabinfo, the size-NNN
>>entries).  usually, there will be a bit space available unless the 
>>pdu happens to be close to one of those power of 2 sizes.
>>
>>    
>>
>
>Excellent news!  So if I do something like
>
>	if (skb_tailroom() is not enough)
>	{
>		skb_copy_expand();
>	}
>	else
>	{
>		append padding and trailer;
>	}
>
>then most of the time the skbuff will have enough tailroom, and the copy
>can be avoided!
>
>This is worth doing as it will improve performance for almost all frame
>sizes.
>
>I'll try it out.
>
>Thanks,
>
>Alex
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Linux-atm-general mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-atm-general
>
>
>  
>