[ Cc netdev and change the subject ] On Mon, 2009-09-14 at 21:06 +0800, Mel Gorman wrote: > > Essentially, the hardware only requires an order-1 allocation aligned on > > 256 bytes boundary. But as it is used as an SKB, a trailing struct > > skb_shared_info is added. This forces us to both increase the order and > > do alignment ourselves. I believe some improvement could be done here. > > But it should not be an easy one. > > > > Probably not. I can only assume that moving the location of > skb_shared_info such that it is sometimes located after the buffer and > sometimes allocated via a separate kmalloc() would be a significant > undertaking. Shall I propose below function as a variant to alloc_skb()? struct sk_buff *alloc_skb_attach_buff(void *data_buff, unsigned int real_size, unsigned int size, gfp_t mask); If real_size >= size + sizeof(struct skb_shared_info), we can still put the shinfo at the end of the buffer. Otherwise we can allocate from a new slab that put sk_buff and shinfo together. Of course, kfree_skbmem() needs to recognize it. This way, device drivers can allocate the Rx buffers with their own size and alignment requirement. i.e. do an order-1 page allocation directly with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx buffer. After DMA is finished, drivers can use the above function to assemble an skb based on the Rx buffer. It should resolve the problem for requiring an order-2 allocation by alloc_skb() in the first place. Comments are welcome. Thanks, -yi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
