On Wed, Nov 06, 2024 at 09:26:44AM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > On Tue, Nov 05, 2024 at 06:32:47PM +0100, Florian Westphal wrote:
> > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > > Thanks, I'd rather convince you this is the way to go, if after
> > > > quickly sketching a patchset you think it is not worth for more
> > > > reasons, we can revisit.
> > >
> > > Untested. I'm not sure about skb_tstamp() usage.
> > > As-is CTA_EVENT_TIMESTAMP in the NEW event would be before
> > > the start time reported as the start time by the timestamp extension.
> >
> > Is there any chance this timestamp can be enabled via toggle?
>
> Can you clarify? Do you mean skb_tstamp() vs ktime_get_real_ns()
> or tstamp sampling in general?
I am referring to ktime_get_real_ns(), I remember to have measured
25%-30% performance drop when this is used, but I have not refreshed
those numbers for long time.
As for skb_tstamp(), I have to dig in the cost of it.
> > > + CTA_EVENT_TIMESTAMP,
> >
> > CTA_TIMESTAMP_EVENT
> >
> > for consistency with CTA_TIMESTAMP_{START,...}
>
> Sure, updated.
