Hi konstantin, @step...@networkplumber.org <step...@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.anan...@huawei.com> wrote: > > > > 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. > > > 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. > > > > >
