From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4FBC0A00C4; Sat, 19 Nov 2022 14:13:22 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 031C440041; Sat, 19 Nov 2022 14:13:22 +0100 (CET) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by mails.dpdk.org (Postfix) with ESMTP id 4B7E14003F; Sat, 19 Nov 2022 14:13:20 +0100 (CET) Received: by mail-pf1-f169.google.com with SMTP id b29so7362544pfp.13; Sat, 19 Nov 2022 05:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=azCGVYgqXrQnZMsGauKvyIq3P7ivX7N2uP7O3QH5/SA=; b=cjuGdkAxwz1bYgGTE22oLsvja7ntpgRnhKn1cxirlQYwkqkSFMP9rmEe51+Dcrl/5l giw01YKWLm/ZsBl6yL1+ioL/hc72N3wKAvaaHlRq3B9aOzojo822MoAKaOJ0grwAFcjV VfRDRi9Au7qFVDVM50NcXSobZXjaIpFHLg/JeoGYux6s9hBvu0ozjV1hMKHV76ppo7Dz dFU69c2h/rFqiBYI7sJv/c7IGb9JETG+RNXKla96nFtR9as9FT+huTYE4VXgHtJhADzZ 8es9OYfqYW/1h4fi29bW+zNPJr4KNb6lJDaEtZmQc+ZAa3eFVzvpitE1n9lULxgoEm1x 8Djg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=azCGVYgqXrQnZMsGauKvyIq3P7ivX7N2uP7O3QH5/SA=; b=ZCRFQwKqiHbeFfXRqwR3q5kkc1U+PwGKYoFy++GNShAc5PI3avO51lNhBONwZkfNvW oE9cfIm7Qd0bqRdtirkj23mUuWaqB8OtahQEoZGzjMZFN50R5PJxG0Rx8240SMDLR/PV m6j6KgAn4E31boyUw7lhsFUdDPSioWWfCeHgXlOFOZevXa6dHIy4hkr9zEHDsidS+yGM GLjSMTi6kP2D05QkjviFrgH3IvCd1axipuLHCMvG7/JzOj0sIJnAHcwCmntvvyQAkY2N 1xXokN0Xo5024Mv7+8eBfJ3h5o2BE2W+iJJjminzZI9EPEQcjtl1Jwf1XQclXa91QNSV 9szg== X-Gm-Message-State: ANoB5pmonuHKnd86b6FLPRB7MTef6CJdtTOeJ6dSWad9IfsrKq6Q0FPG xcpQSKQibgE4P5LFg9hxdDVXZsnl9W3UtqtpiLw= X-Google-Smtp-Source: AA0mqf7/sMYM/ksvipv3gt1eLTJAphg6CASbyhayYNLEk4cHQEanmSjw6fJk+nbxQAjNgr8YewC6+kwv+EzpNdRtkgM= X-Received: by 2002:aa7:9293:0:b0:56b:9bf4:c1c4 with SMTP id j19-20020aa79293000000b0056b9bf4c1c4mr1445241pfa.67.1668863599175; Sat, 19 Nov 2022 05:13:19 -0800 (PST) MIME-Version: 1.0 References: <20221117145241.503fd10b@hermes.local> <3755f0338ad546a9934644c7847b8c74@huawei.com> In-Reply-To: <3755f0338ad546a9934644c7847b8c74@huawei.com> From: venkatesh bs Date: Sat, 19 Nov 2022 18:43:09 +0530 Message-ID: Subject: Re: Regarding User Data in DPDK ACL Library. To: Konstantin Ananyev Cc: Stephen Hemminger , "users@dpdk.org" , "dev@dpdk.org" Content-Type: multipart/alternative; boundary="00000000000001edef05edd2962f" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --00000000000001edef05edd2962f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 =E2=80=94 Data Plane Dev= elopment > Kit > > > 22.11.0-rc2 documentation (dpdk.org) > > > > > > > > > - *userdata*: A user-defined value. For each category, a successfu= l > > > 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 AB= I > breakage. > > > Always its > > > possible that User Data in Application Can be 64bit long, But since 6= 4 > 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. > > > > > --00000000000001edef05edd2962f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0 konstantin,=C2=A0@stephen@networkplumber.org

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

Thanks & Regards,
Venkates= h.


On Fri, Nov 18, 2022 at 4:01 PM Konstantin Ananyev &= lt;konstantin.ananyev@huaw= ei.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 =E2=80=94 Data Plane= Development Kit
> > 22.11.0-rc2 documentation (dpdk.org)
> >
> >
> >=C2=A0 =C2=A0 - *userdata*: A user-defined value. For each categor= y, a successful
> >=C2=A0 =C2=A0 match returns the userdata field of the highest prio= rity matched rule. When
> >=C2=A0 =C2=A0 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 sav= ings
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 sin= ce 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 vi= ce versa
> > after classification.
> >
> > I Wonder if anyone would have faced this issue, Please suggest an= y
> > suggestions if somewhere am wrong in understanding/Possible Solut= ion 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 32= bits),
but that's a bit too awkward from my perspective.




--00000000000001edef05edd2962f--