Re: [RFC] Wild and crazy ideas involving struct sk_buff

[David Miller <davem@davemloft.net>]

From: Paul Moore <paul.moore@hp.com>
Date: Wed, 22 Aug 2007 16:31:34 -0400

> We're currently talking about several different ideas to solve the problem, 
> including leveraging the sk_buff.secmark field, and one of the ideas was to 
> add an additional field to the sk_buff structure.  Knowing how well that idea 
> would go over (lead balloon is probably an understatement at best) I started 
> looking at what I might be able to remove from the sk_buff struct to make 
> room for a new field (the new field would be a u32).  Looking at the sk_buff 
> structure it appears that the sk_buff.dev and sk_buff.iif fields are a bit 
> redundant and removing the sk_buff.dev field could free 32/64 bits depending 
> on the platform.  Is there any reason (performance?) for keeping the 
> sk_buff.dev field around?  Would the community be open to patches which 
> removed it and transition users over to the sk_buff.iif field?  Finally, 
> assuming the sk_buff.dev field was removed, would the community be open to 
> adding a new LSM/SELinux related u32 field to the sk_buff struct?

It's there for performance, and I bet there might be some semantic
issues involved.

And ironically James Morris still owes me a struct sk_buff removal
from when I let him put the "secmark" thing in there!

Stop spending money you guys haven't earned yet :-)