From: Paolo Abeni <pabeni@redhat.com>
To: Martin KaFai Lau <kafai@fb.com>, Wei Wang <weiwan@google.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next] ipv6: only update __use and lastusetime once per jiffy at most
Date: Sun, 15 Oct 2017 15:01:32 +0200 [thread overview]
Message-ID: <1508072492.2847.5.camel@redhat.com> (raw)
In-Reply-To: <20171014000924.dcfuqxwlalaigqdq@kafai-mbp.dhcp.thefacebook.com>
On Fri, 2017-10-13 at 17:09 -0700, Martin KaFai Lau wrote:
> On Fri, Oct 13, 2017 at 10:08:07PM +0000, Wei Wang wrote:
> > From: Wei Wang <weiwan@google.com>
> >
> > In order to not dirty the cacheline too often, we try to only update
> > dst->__use and dst->lastusetime at most once per jiffy.
>
>
> > As dst->lastusetime is only used by ipv6 garbage collector, it should
> > be good enough time resolution.
>
> Make sense.
>
> > And __use is only used in ipv6_route_seq_show() to show how many times a
> > dst has been used. And as __use is not atomic_t right now, it does not
> > show the precise number of usage times anyway. So we think it should be
> > OK to only update it at most once per jiffy.
>
> If __use is only bumped HZ number of times per second and we can do ~3Mpps now,
> would __use be way off?
It would, but even nowaday such value could not be trusted, due to the
cuncurrent non atomic operation used to update it.
This:
https://marc.info/?l=linux-netdev&m=150653252930953&w=2
was an attempt to preserve a more meaningful value for '__use', but it
requires an additional cacheline.
I'm fine with either options.
Paolo
next prev parent reply other threads:[~2017-10-15 13:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 22:08 [PATCH net-next] ipv6: only update __use and lastusetime once per jiffy at most Wei Wang
2017-10-14 0:09 ` Martin KaFai Lau
2017-10-14 0:26 ` Eric Dumazet
2017-10-15 18:19 ` Martin KaFai Lau
2017-10-15 13:01 ` Paolo Abeni [this message]
2017-10-16 20:09 ` 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=1508072492.2847.5.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=weiwan@google.com \
/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.