> > 	I'm still wondering what kind of format is good for "aux" portion.
> > 	I'm thinking about tagging mbuf on "aux" chain with commonly formatted
> > 	data item like:
> > 		struct tag {
> > 			u_int8_t proto;
> > 			u_int8_t code;
> > 		};
>This seems okay, but remember this is going to be padded out on most
>platforms, so you might just consider making them "int"s, or something.

	I'm okay with integers.

> > 	downside of this is, of course, MHLEN becomes smaller by addition
> > 	of pointer item.  having generic data item to "aux", I hope to
> > 	avoid future member addition to mbuf structure.
>Yah, that's annoying.  Maybe we should increase MSIZE to 256 across the
>board?  The Alpha and Sparc64 will still lose space (because they already
>have MSIZE == 256), but I don't see what harm will come to other ports,
>really, unless they are otherwise seriously memory-starved already.

	I think platforms like i386 (with more horsepower/memoryspace)
	are okay.  i hope to hear from users of more memory-limited platforms.

	with MHLEN decrease, we may see some of "MHLEN is sufficiently large"
	assumption breaks - we may need to put DIAGNOSTIC here and there
	to be sure.

> > 	If it is okay to add this member, first step would be to use "aux"
> > 	just to avoid overloading of m->m_pkthdr.rcvif to help if_detach and
> > 	packet filters.  then, we'll implement extra mbuf chain handling
> > 	and put socket information and other things into "aux"chain.
> > 	I'll test it in KAME tree and bring it into netbsd, hopefully very soon.
> > 	Comments/suggestions/whatever?
>Yes, that's great... I really want to stop overloading `rcvif' ... because
>I'm currently working on if_detach :-)

	i'll try to commit the "first step" sooner.  it's on my machine
	and working fine.

> >  struct	pkthdr {
> >  	struct	ifnet *rcvif;		/* rcv interface */
> >  	int	len;			/* total packet length */
> > +	struct mbuf *aux;		/* aux data buffer; ipsec and others */
> >  };
>I have a concern here... you're going to waste space on LP64 platforms
>with this arrangement... it should be:
>	struct ifnet *rcvif;
>	struct mbuf *aux;
>	int len;

	I'm happy with the above.

>But then its an ABI change for LKMs.  I guess people will have to recompile
>IP Filter.  This will warrant a version number bump (to 1.4R).

	(I hope I do not misread "but then" here)
	Let me check... LKMs with old mbuf.h are not usable regardless from
	the ordering of pkthdr member, due to position change in m_pktdat
	(M_dat.MH.MH_dat.MH_databuf), and MHLEN change.  if we use old LKM
	on new kernel, LKM will overwrite pkthdr portion by mistake.
	Am I correct?

itojun