From: Deepa Dinamani <deepa.kernel@gmail.com>
To: willemdebruijn.kernel@gmail.com
Cc: "David S. Miller" <davem@davemloft.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Network Devel Mailing List <netdev@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
y2038 Mailman List <y2038@lists.linaro.org>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Ralf Baechle <ralf@linux-mips.org>,
rth@twiddle.net, linux-alpha@vger.kernel.org,
"open list:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
Parisc List <linux-parisc@vger.kernel.org>,
linux-rdma@vger.kernel.org,
sparclinux <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v2 6/8] socket: Add SO_TIMESTAMP[NS]_NEW
Date: Sat, 15 Dec 2018 12:56:07 -0800 [thread overview]
Message-ID: <CABeXuvr7je=LG9+xO286b7HH2WNLSfoOL4V6nN0AkjsGr_SoCQ@mail.gmail.com> (raw)
In-Reply-To: <CAF=yD-KFYdXRgL-HpAJLLHuywMcaBGfz7sDL35DBNs0hoq+zxQ@mail.gmail.com>
> > Also for the other comment. The reason the conditionals were not
> > consistent is because they were not consistent to begin with.
>
> The only difference I see is an inversion of the test. Nesting order
> is the same:
>
> int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
> ...
> if (need_software_tstamp) {
> if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
> }
>
> vs
>
> if (sock_flag(sk, SOCK_RCVTSTAMP)) {
> if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
> }
>
> I suggest just adding something like
>
> if (need_software_tstamp) {
> + if (sock_uses_new_tstamp(sk) {
> + __sock_recv_timestamp_new(msg, sk,
> ktime_to_timespec64(skb->tstamp));
> + } else if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> - if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
>
> and
>
> if (sock_flag(sk, SOCK_RCVTSTAMP)) {
> + if (sock_uses_new_tstamp(sk) {
> + __sock_recv_timestamp_new(msg, sk, ts);
> + else if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> - if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
>
> I think we can use the same helper for both the sock and tcp variant.
> The only intended difference between the two functions, as described
> in the tcp_recv_timestamp function comment, is the absence of an skb
> in the tcp case. That is immaterial at this level.
I will just not refactor things into a function: __sock_rescv_timestamp_new().
I will just add new conditionals for the new timestamps.
When you guys refactor the other timestamp stuff like you mentioned
below maybe you can move the new timestamps to a new funtcion as you
see fit.
The helper functions in skbuff.h might first need to be refactored
first. But I again leave this to you guys.
> Note also (2) tentative helper function sock_uses_new_tstamp(const
> struct sock *sk) instead of testing sock_flag(sk, SOCK_TSTAMP_NEW)
> directly. Since the .._NEW variants are equivalent to .._OLD on 64-bit,
> I wonder if we can just compile out the branch. Something like
>
> static inline bool sock_uses_new_tstamp(const struct sock *sk) {
> return (sizeof(time_t) != sizeof(__kernel_long_t)) &&
> sock_flag(sk, SOCK_TSTAMP_NEW);
> }
>
You could just ifdef CONFIG_64BIT if you are worried about branching.
Note that SO_TIMESTAMP is by default SO_TIMESTAMP_OLD on 64 bit machines.
But, I will again leave the optimization to you. I will implement in a
straight forward way and you guys can deicde how you want to optimize
the fast path or what should it even be.
-Deepa
next prev parent reply other threads:[~2018-12-15 20:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 20:25 [PATCH v2 0/8] net: y2038-safe socket timestamps Deepa Dinamani
2018-12-11 20:25 ` [PATCH v2 2/8] sockopt: Rename SO_TIMESTAMP* to SO_TIMESTAMP*_OLD Deepa Dinamani
2018-12-11 20:25 ` [PATCH v2 6/8] socket: Add SO_TIMESTAMP[NS]_NEW Deepa Dinamani
2018-12-12 15:22 ` Willem de Bruijn
2018-12-12 15:35 ` Willem de Bruijn
2018-12-15 1:07 ` Deepa Dinamani
2018-12-15 15:11 ` Willem de Bruijn
2018-12-15 16:50 ` Deepa Dinamani
2018-12-15 18:51 ` Willem de Bruijn
2018-12-15 20:56 ` Deepa Dinamani [this message]
2018-12-18 16:33 ` Arnd Bergmann
2018-12-18 21:27 ` Deepa Dinamani
2018-12-14 23:24 ` [PATCH v2 0/8] net: y2038-safe socket timestamps David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABeXuvr7je=LG9+xO286b7HH2WNLSfoOL4V6nN0AkjsGr_SoCQ@mail.gmail.com' \
--to=deepa.kernel@gmail.com \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=jejb@parisc-linux.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=rth@twiddle.net \
--cc=sparclinux@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).