The release notes for 17.10 haven’t been written yet, but they’re on their way!
We normally have an empty template for the upcoming release to avoid this sort of confusion, but it sometimes gets missed; it’s just a detail. Chris. From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Yuliang Li Sent: Tuesday, October 17, 2017 10:43 AM To: Ole Troan <otr...@employees.org> Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] SNAT hash tables The RELEASE.md says it is for 17.04. But in vppctl, 'show ver' shows I am using v17.10-rc0~19-g58eb866 What is latest version? Thanks, Yuliang On Tue, Oct 17, 2017 at 3:01 AM, Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> wrote: Yuliang, > Get it. It use spinlock (in vppinfra/bihash_template.c): > > while (__sync_lock_test_and_set (h->writer_lock, 1)) > > On Mon, Oct 16, 2017 at 11:39 AM, Yuliang Li > <yuliang...@yale.edu<mailto:yuliang...@yale.edu>> wrote: > Hi all, > > I am curious in the SNAT implementation. I see that SNAT's hash tables are > shared by all worker threads. Does SNAT use lock to avoid multiple threads > updating the hash table concurrently? If not, how does it avoid race > condition? Are you on latest? The "global" NAT state space is essentially split across all workers. So there is no locking. typedef struct { /* Main lookup tables */ clib_bihash_8_8_t out2in; clib_bihash_8_8_t in2out; /* Find-a-user => src address lookup */ clib_bihash_8_8_t user_hash; /* User pool */ snat_user_t * users; /* Session pool */ snat_session_t * sessions; /* Pool of doubly-linked list elements */ dlist_elt_t * list_pool; u32 snat_thread_index; } snat_main_per_thread_data_t; Best regards, Ole -- Yuliang Li PhD student Department of Computer Science Yale University
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
