RE: Regarding User Data in DPDK ACL Library.

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Monday, November 21, 2022 4:57 PM
> To: Konstantin Ananyev <konstantin.ananyev@huawei.com>; Stephen Hemminger <stephen@networkplumber.org>; venkatesh bs
> <venki.bsv@gmail.com>
> Cc: users@dpdk.org; dev@dpdk.org; nd <nd@arm.com>; nd <nd@arm.com>
> Subject: RE: Regarding User Data in DPDK ACL Library.
> 
> <snip>
> >
> > > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs
> > > > > <venki.bsv@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