RE: Regarding User Data in DPDK ACL Library.

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<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.
Ok, then the ordering does not matter, all the loads on the data plane should be relaxed and not atomic (searching through the code does not show any).

> Konstantin
> 
>