<snip> > > > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs > > > > <venki....@gmail.com> wrote: > > > > > > > > > Hi DPDK Team, > > > > > > > > > > After the ACL match for highest priority DPDK Classification API > > > > > returns User Data Which is as mentioned below in the document. > > > > > > > > > > 53. Packet Classification and Access Control — Data Plane > > > > > Development Kit > > > > > 22.11.0-rc2 documentation (dpdk.org) > > > > > > > > > > > > > > > - *userdata*: A user-defined value. For each category, a successful > > > > > match returns the userdata field of the highest priority matched > rule. > > > When > > > > > no rules match, returned value is zero > > > > > > > > > > I Wonder Why User Data Support does not returns 64 bit values, > > > > > > As I remember if first version of ACL code it was something about > > > space savings to improve performance... > > > Now I think it is more just a historical reason. > > > It would be good to change userdata to 64bit, but I presume it will > > > be ABI breakage. > > Agree. We should support 64b and even 128b (since architectures > > support 128b atomic operations). This reduces required memory barriers > required if the data size <= the size of atomic operations. > > Hmm... sorry, didn’t get you here. > I do understand the user intention to save pointer to arbitrary memory > location as user-data (64-bit). > But how does the size of atomic mem-ops relate? > Konstantin What I meant is, if your data fits within 64b or 128b, having another indirection requires:
1) one additional memory operation to store the data (the first one being the store to the index) 2) on the control plane, we would need a release barrier between 'store data' and 'store index' (not a significant issue). On the data plane, we could use relaxed ordering between 'load index' and 'load data', so we do not need a barrier here. So, looks like there is no barrier over-head on the data plane, but overhead of one additional memory operation.
