[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070822.140805.54950393.davem@davemloft.net>
Date: Wed, 22 Aug 2007 14:08:05 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: paul.moore@...com
Cc: netdev@...r.kernel.org, jmorris@...ei.org
Subject: Re: [RFC] Wild and crazy ideas involving struct sk_buff
From: Paul Moore <paul.moore@...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 :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists