* Herbert Xu [ref] 2005-01-29 10:22

Thomas Graf [off-list ref] wrote:

quoted

The current value doesn't make much sense anymore because
skb_shared_info isn't taken into account which means that
depending on the architecture NLMSG_GOOSIZE can exceed PAGE_SIZE
resulting in a waste of almost a complete page.

You're quite right.

quoted

Using SKB_MAXORDER solves this potential leak at the cost of
slightly smaller but safer sizes for some architectures.

At first glance it's not clear which of sk_buff or skb_shared_info
is bigger.  So it might even end up being bigger :)

skb_shared_info is 160 bytes and sk_buff is 196 bytes on my box (x86)
but that's not the point. We need to take SMP_CACHE_BYTES alignment into
account which tends to be quite big. The original NLMSG_GOODSIZE
results in 3908 on my box and gets pumped up to 4128 by skb_alloc
(ALIGN(...,SMP_CACHE_BYTES) + sizeof(struct skb_shared_info)) having
SMP_CACHE_BYTES at 128. 

quoted

-#define NLMSG_GOODSIZE (PAGE_SIZE - ((sizeof(struct sk_buff)+0xF)&~0xF))
+#define NLMSG_GOODORDER 0
+#define NLMSG_GOODSIZE (SKB_MAX_ORDER(0, NLMSG_GOODORDER))

Are we ever going use NLMSG_GOODORDER for anything? If not why don't
we go straight to NLMSG_GOODSIZE?

My thought behind it is that it clearly documents that we use order-0
allocation and we can easly bump it up if we need more space but it's
basically just cosmetic.