From: Paolo Abeni <pabeni@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next] sock: avoid dirtying sk_stamp, if possible
Date: Thu, 30 Mar 2017 16:23:49 +0200 [thread overview]
Message-ID: <1490883829.2616.18.camel@redhat.com> (raw)
In-Reply-To: <1490881940.24891.66.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, 2017-03-30 at 06:52 -0700, Eric Dumazet wrote:
> On Thu, 2017-03-30 at 14:03 +0200, Paolo Abeni wrote:
> > sock_recv_ts_and_drops() unconditionally set sk->sk_stamp for
> > every packet, even if the SOCK_TIMESTAMP flag is not set in the
> > related socket.
> > If selinux is enabled, this cause a cache miss for every packet
> > since sk->sk_stamp and sk->sk_security share the same cacheline.
> > With this change sk_stamp is set only if the SOCK_TIMESTAMP
> > flag is set, and is cleared for the first packet, so that the user
> > perceived behavior is unchanged.
> >
> > This gives up to 5% speed-up under udp-flood with small packets.
> >
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> > include/net/sock.h | 5 ++++-
> > net/core/sock.c | 2 +-
> > 2 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index cb241a0..8e53158 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -2239,6 +2239,7 @@ sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
> > void __sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
> > struct sk_buff *skb);
> >
> > +#define SK_DEFAULT_STAMP (-1L * NSEC_PER_SEC)
> > static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
> > struct sk_buff *skb)
> > {
> > @@ -2249,8 +2250,10 @@ static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
> >
> > if (sk->sk_flags & FLAGS_TS_OR_DROPS || sk->sk_tsflags & TSFLAGS_ANY)
> > __sock_recv_ts_and_drops(msg, sk, skb);
> > - else
> > + else if (unlikely(sk->sk_flags & SOCK_TIMESTAMP))
> > sk->sk_stamp = skb->tstamp;
> > + else if (unlikely(sk->sk_stamp == SK_DEFAULT_STAMP))
> > + sk->sk_stamp = 0;
> > }
> >
>
> This looks very nice, but why using 0 here instead of skb->tstamp ?
Thank you for reviewing this.
The network stack can already mark sk->sk_stamp with 0, if the
'netstamp_needed' static key is false when the packet is received.
'0' is used as a special value by sock_get_timestamp(), providing to
the caller the current ktime.
This way the kernel is able to detect if no packets have been received
and to provide a somewhat valid timestamp for the last packet received
before that the SOCK_TIMESTAMP flag was enabled; the assumption is that
the ioctl() follows closely the read call.
This should be the same behavior the user space already observes if net
timestamping is disabled when the SOCK_TIMESTAMP flag is set.
> This might give some regression on applications reading their first
> socket timestamp in some contexts.
>
> What about
>
> if (sk->sk_flags & FLAGS_TS_OR_DROPS || sk->sk_tsflags & TSFLAGS_ANY)
> __sock_recv_ts_and_drops(msg, sk, skb);
> else if (unlikely(sk->sk_flags & SOCK_TIMESTAMP ||
> sk->sk_stamp == SK_DEFAULT_STAMP))
> sk->sk_stamp = skb->tstamp;
That way, if the net timestamp is enable, we will record the timestamp
of the first packet received by the socket (it can be far away in the
past).
I think is just a different kind of approximation.
Cheers,
Paolo
next prev parent reply other threads:[~2017-03-30 14:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 12:03 [PATCH net-next] sock: avoid dirtying sk_stamp, if possible Paolo Abeni
2017-03-30 13:52 ` Eric Dumazet
2017-03-30 14:23 ` Paolo Abeni [this message]
2017-03-30 15:37 ` Eric Dumazet
2017-03-31 3:29 ` David Miller
2017-03-31 21:59 ` [PATCH net-next] sock: correctly test SOCK_TIMESTAMP in sock_recv_ts_and_drops() Eric Dumazet
2017-03-31 23:36 ` Paolo Abeni
2017-04-03 2:35 ` 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=1490883829.2616.18.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.