> > > > > > > > > > > > After evaluating long term API/ABI issues, I think you need to > > > > > > get rid of almost all use of inline and visible structures. > > > > > > Yes it might be marginally slower, but you thank me the first time > you have to fix something. > > > > > > > > > > > Agree, I was planning on another version to address this (I am yet > to take a look at your patch addressing the ABI). > > > > > The structure visibility definitely needs to be addressed. > > > > > For the inline functions, is the plan to convert all the inline > > > > > functions in DPDK? If yes, I think we need to consider the > > > > > performance > > > > difference. May be consider L3-fwd application, change all the inline > functions in its path and run a test? > > > > > > > > Every function that is not in the direct datapath should not be inline. > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and > > > > packet alloc/free > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc. > > > I think rcu should be one of such exceptions - it is just another > > > synchronization mechanism after all (just a bit more sophisticated). > > > Konstantin > > > > If you look at the other userspace RCU, you wil see that the only > > inlines are the rcu_read_lock,rcu_read_unlock and > rcu_reference/rcu_assign_pointer. > > > > The synchronization logic is all real functions. > > In fact, I think urcu provides both flavors: > https://github.com/urcu/userspace- > rcu/blob/master/include/urcu/static/urcu-qsbr.h > I still don't understand why we have to treat it differently then let say > spin-lock/ticket-lock or rwlock. > If we gone all the way to create our own version of rcu, we probably want > it to be as fast as possible (I know that main speedup should come from > the fact that readers don't have to wait for writer to finish, but still...) > Except for ' rte_rcu_qsbr_synchronize' (will correct in the next version), we have the correct APIs marked as inline. They all are part of the fast path.
> Konstantin
