On Thu, Nov 25, 2021 at 05:34:27PM +0100, Paolo Valerio wrote: > Flavio Leitner <[email protected]> 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 <[email protected]> > >> --- > >> 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. fbl _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
