On Sun, 2005-24-07 at 19:07 -0700, David S. Miller wrote: > From: Thomas Graf <[EMAIL PROTECTED]> > Date: Mon, 25 Jul 2005 03:31:18 +0200 > > > Anyways, tc_verd needs a serious cleanup, not just for the > > macros which we might want to replace with bitfields or > > at least have generic macros to generate the masks. I'll > > look into this once I'm back. > > I think tc_verd is yet another instance of something the > classifier layer is storing in the SKB which belongs in > function parameters and return values. >
Most cant actually be moved out of the skb because they have global meanings (maybe for one bit which i need to go consult my notes for). I should documents this stuff, but i doodled this to Thomas on a piece of paper: We have a graph essentially of where the packet could flow to/from. packets could move around ingress/egress/upperlayers etc. The bits are hints from different layers to other (or even from same layer to itself). > input_dev, tc_verd, etc. they are all sitting in the SKB > because nobody bothered to add them to the ->queue() and > clasification code path function arguments and return values > > In fact most of the excess in SKB is of this nature, pure > parameter passing. true. ->cb could be used or made to grow dynamically ? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
