Hi  konstantin, @stephen@networkplumber.org

Thanks for the reply and your suggestions. I will try to see what can best fit into my application.

Thanks & Regards,
Venkatesh.


On Fri, Nov 18, 2022 at 4:01 PM Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:


> 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.

> 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.