> -----Original Message----- > From: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > Sent: Monday, November 21, 2022 4:57 PM > To: Konstantin Ananyev <konstantin.anan...@huawei.com>; Stephen Hemminger > <step...@networkplumber.org>; venkatesh bs > <venki....@gmail.com> > Cc: us...@dpdk.org; dev@dpdk.org; nd <n...@arm.com>; nd <n...@arm.com> > Subject: RE: Regarding User Data in DPDK ACL Library. > > <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.
ACL doesn't provide ability to dynamically update the rules or associated user-data. Whole ACL table has to be rebuild. Konstantin
