[ovs-dev] [PATCH v2 2/4] Native tunnel: Add tnl/neigh/aging command.
fbl at sysclose.org
Thu Nov 25 18:04:32 UTC 2021
On Thu, Nov 25, 2021 at 05:34:27PM +0100, Paolo Valerio wrote:
> Flavio Leitner <fbl at sysclose.org> writes:
> > On Wed, Nov 10, 2021 at 11:46:42AM +0100, Paolo Valerio wrote:
> >> with the command is now possible to change the aging time of the
> >> cache entries.
> >> For the existing entries the aging time is updated only if the
> >> current expiration is greater than the new one. In any case, the next
> >> refresh will set it to the new value.
> >> This is intended mostly for debugging purpose.
> >> Signed-off-by: Paolo Valerio <pvalerio at redhat.com>
> >> ---
> >> v2:
> >> - fixed NEIGH_ENTRY_MAX_AGEING_TIME (turned to seconds) correcting a
> >> leftover.
> >> - turned relaxed atomics to acq/rel.
> >> - added range checks to tunnel-push-pop.at. It was useless to
> >> duplicate the test for both ipv6 and ipv4, so only the latter
> >> includes it.
> >> - slightly modified the NEWS entry.
> >> ---
> >> NEWS | 2 +
> >> lib/tnl-neigh-cache.c | 79 +++++++++++++++++++++++++++++++++++----
> >> ofproto/ofproto-tnl-unixctl.man | 9 ++++
> >> tests/tunnel-push-pop-ipv6.at | 30 +++++++++++++++
> >> tests/tunnel-push-pop.at | 47 +++++++++++++++++++++++
> >> 5 files changed, 158 insertions(+), 9 deletions(-)
> >> diff --git a/NEWS b/NEWS
> >> index 434ee570f..1aa233a0d 100644
> >> --- a/NEWS
> >> +++ b/NEWS
> >> @@ -16,6 +16,8 @@ Post-v2.16.0
> >> - ovs-dpctl and 'ovs-appctl dpctl/':
> >> * New commands 'cache-get-size' and 'cache-set-size' that allows to
> >> get or configure linux kernel datapath cache sizes.
> >> + - ovs-appctl:
> >> + * New command tnl/neigh/aging to read/write the neigh aging time.
> >> v2.16.0 - 16 Aug 2021
> >> diff --git a/lib/tnl-neigh-cache.c b/lib/tnl-neigh-cache.c
> >> index 1e6cc31db..a4d56e4cc 100644
> >> --- a/lib/tnl-neigh-cache.c
> >> +++ b/lib/tnl-neigh-cache.c
> >> @@ -46,6 +46,7 @@
> >> #define NEIGH_ENTRY_DEFAULT_IDLE_TIME_MS (15 * 60 * 1000)
> >> +#define NEIGH_ENTRY_MAX_AGING_TIME 3600
> > Shouldn't we include the unit suffix here too?
> We could. For consistency, I think we should add "_S".
Yup, that's fine by me.
> Is it ok, or you prefer something else like _SEC?
Well, as you pointed out, the consistency matters, so
in that case I think _MS should have been _MSEC as well.
More information about the dev