On 12/3/21 16:59, Paolo Valerio wrote: > Gaëtan Rivet <gr...@u256.net> writes: > >> On Sat, Nov 27, 2021, at 00:12, Paolo Valerio wrote: >>> v3: >>> - added _S suffix to NEIGH_ENTRY_MAX_AGING_TIME (patch #2) >>> - Added Reported-at tag (patch #4) >>> >>> v2: >>> - rebased against master >>> - turned 'ageing' -> 'aging' >>> - further details of v1 -> v2 respin has been added >>> to each patch >>> >>> The series is composed of the following patches: >>> >>> #1: Expires is modified in different contexts (revalidator, pmd-rx, bfd-tx). >>> It's probably not very racy for many reasons, but it seems a good idea >>> to use an atomic here (especially with the introduction of #3). >>> >>> #2: Introduces the possibility to set and read the entries timeout. >>> It's useful for debugging purpose. Includes a self-test. >>> >>> #3: While performing some tests I noticed unstable timeouts (more >>> visible when the ageing time is low) during nd snoop. >>> It turned out to be a problem of revalidation. Additional >>> details can be found in the commit description. >>> >>> #4: Fixes a use case in which the tnl neigh entry never >>> gets updated (further details in the commit message). >>> Includes a self-test. >>> >>> The use case fixed in #4 could be fixed relaxing the check in >>> tnl_arp_snoop(), allowing to snoop ARP requests as well, but such >>> approach could add unneeded entries in the cache. >>> >>> Paolo Valerio (4): >>> Native tunnel: Read/write expires atomically. >>> Native tunnel: Add tnl/neigh/aging command. >>> Native tunnel: Do not refresh the entry while revalidating. >>> Tunnel: Snoop ingress packets and update neigh cache if needed. >>> >> >> Hello Paolo, >> >> Thanks for adressing the remarks. >> There is a trivial conflict on NEWS with current master but otherwise LGTM. >> >> For the series: >> Acked-by: Gaetan Rivet <gr...@u256.net> >> > > Thank you Gaetan. > > Ilya, do you want me to respin for the conflict on NEWS? >
Nope. There is no need to repsin only for a NEWS conflict. These are typically easy to resolve. And it's also hard to avoid them. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
