On Tue, May 02, 2017 at 10:58 -0600, Theo de Raadt wrote:
> Most important reason to me is less mbuf growth
>
> But what units is this timestamp...
>
Right now it's up to the code using it with a preference for a
nanosecond precision, but once we start using it for more than
one thing, we can fix the precision.
> > As it appears, there's an argument to use a single 64 bit integer
> > instead. Whether use a signed or value or not is debatable, but
> > here's an argument to go for signed: time_t, timespec and timeval
> > are all signed. I didn't specify the desired precision in the
> > comment here and left it up to the implementation
> >
> > OK?
> >
> > ---
> > sys/sys/mbuf.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git sys/sys/mbuf.h sys/sys/mbuf.h
> > index 202ce8ced8b..7ca1a779fe0 100644
> > --- sys/sys/mbuf.h
> > +++ sys/sys/mbuf.h
> > @@ -127,10 +127,11 @@ struct pkthdr {
> > u_int16_t ph_flowid; /* pseudo unique flow id */
> > u_int16_t csum_flags; /* checksum flags */
> > u_int16_t ether_vtag; /* Ethernet 802.1p+Q vlan tag */
> > u_int ph_rtableid; /* routing table id */
> > u_int ph_ifidx; /* rcv interface index */
> > + int64_t ph_timestamp; /* packet timestamp */
> > u_int8_t ph_loopcnt; /* mbuf is looping in kernel */
> > struct pkthdr_pf pf;
> > };
> >
> > /* description of external storage mapped into mbuf, valid if M_EXT set */
> > --
> > 2.12.2
> >
> >
>
