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.

> 
> > Always its
> > > possible that User Data in Application Can be 64bit long, But since
> > > 64 bit User data can't be returned by DPDK ACL Library, Application
> > > should have the conversion algorithm from 64 to 32 bit during Rule
> > > add and vice versa after classification.
> > >
> > > I Wonder if anyone would have faced this issue, Please suggest any
> > > suggestions if somewhere am wrong in understanding/Possible Solution
> > > if someone has already gone through this issue.
> > >
> > > Thanks In Advance.
> > > Regards,
> > > Venkatesh B Siddappa.
> >
> > It looks like all users of this API use the userdata to be the index
> > into a table of application specific rules.
> 
> Yes, that's the most common way.
> Another one would be always (build/search) acl rules with two categories:
> rule for both categories will be identical, while data different (low/ho 32bits),
> but that's a bit too awkward from my perspective.
> 
> 
>