netdev - Re: [RFC 0/4] net: enable timestamps on a per-socket basis

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 20 Apr 2008 23:03:56 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	juhlenko@...mai.com
Cc:	netdev@...r.kernel.org, shemminger@...ux-foundation.org
Subject: Re: [RFC 0/4] net: enable timestamps on a per-socket basis

From: Jason Uhlenkott <juhlenko@...mai.com>
Date: Sun, 20 Apr 2008 22:34:02 -0700

> This patchset creates a mechanism for protocols to opt in to handling
> timestamps at a higher layer, and uses this mechanism to implement
> per-socket SOCK_TIMESTAMP support for several common protocols.

Moving the timestamp up to a higher level takes away some of the
frequent use cases of timestamps, which is to detect things like the
fact that it is taking a long time for packets to get from the
top-level packet receive down to the actual protocol processing.

With your patch, it can't be used that way any more.

In fact, people are desiring timestamps which are _closer_ to when the
device actually receives the frame rather than further away.

I understand the reasons why this change is desirable from a
performance standpoint, but we really can't do this, sorry.

It's probably more tenable to do the work necessary get get named to
not enable timestamps by default.  It if really wants packet data
timestamps, it can do a gettimeofday() call right after recvmsg() as
gettimeofday() is merely a function call into the VSYSCALL page on
most platforms.

--
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