Regarding User Data in DPDK ACL Library.

Regarding User Data in DPDK ACL Library.

[venkatesh bs]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1666 bytes --]

Re: Regarding User Data in DPDK ACL Library.

[Stephen Hemminger]

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

RE: Regarding User Data in DPDK ACL Library.

[Konstantin Ananyev]

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

Re: Regarding User Data in DPDK ACL Library.

[venkatesh bs]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

Hi  konstantin, @stephen@networkplumber.org <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.
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3115 bytes --]

RE: Regarding User Data in DPDK ACL Library.

[Honnappa Nagarahalli]

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

RE: Regarding User Data in DPDK ACL Library.

[Konstantin Ananyev]

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

RE: Regarding User Data in DPDK ACL Library.

[Honnappa Nagarahalli]

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

RE: Regarding User Data in DPDK ACL Library.

[Konstantin Ananyev]

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

RE: Regarding User Data in DPDK ACL Library.

[Honnappa Nagarahalli]

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