Hi Andreas,
Great question! I am ccing to the list as well. I don’t think the VPP-UPG uses VPP classifier API, does it? I used the following recursive grep in the root directory for VPP-UPG and didn’t incur any hit. These are the API for using the VPP classifier. grep -R macip_create_classify_tables grep -R classify_add_del_table grep -R acl_classify_add_del_table_small grep -R macip_create_classify_tables grep -R vnet_classify_add_del_session The other point is that I am developing a compiler to convert P4 to a VPP plugin. I picked a UPF P4 program because the program uses lot of networking features so that I can test the compiler P4 features. One example is recursive packet parsing for GTPU extensions, using IP prefix matching, and using range for layer-4 ports for both ip4 and ip6. The past P4 to a VPP plugin work was PVPP (Barefoot Networks, Cisco, Stanford U., and Cornell U.) which did not even develop a P4 compiler (p4c) or what is called as a p4c backend. PVPP cobbled together scripts to parse JSON output of p4c bmv2 backend and used a COG generator to generate VPP plugin code. Additionally, this effort just tested ip4 forwarding with mac rewrite (a baby app) which VPP supports metadata and actions for in the classifier entry. Best wishes, Hemant From: Andreas Schultz <andreas.schu...@travelping.com> Sent: Wednesday, January 20, 2021 8:04 AM To: hem...@mnkcg.com Subject: Re: [vpp-dev] classifier howto? Hi, It seems you are trying to build a UPF based on VPP. Have you seen the VPP-UPG [1] project that is doing the same and is already quite functional? Regards Andreas [1]: https://github.com/travelping/upg-vpp Am Mi., 20. Jan. 2021 um 13:56 Uhr schrieb hemant via lists.fd.io <http://lists.fd.io> <hemant=mnkcg....@lists.fd.io <mailto:mnkcg....@lists.fd.io> >: A github link is included in the JIRA issue to articulate the use case, https://jira.fd.io/browse/VPP-1967 The github link has a value for a classifier entry shown: https://github.com/FDio/vpp/pull/33 The value is a value used in a 5G UPF. The classifier entry's metadata cannot support such a value. Thanks for the pool of values idea. Yes, if vlib_buffer_t is not modified, I will incur another lookup. Best wishes, Hemant -----Original Message----- From: Benoit Ganne (bganne) <bga...@cisco.com <mailto:bga...@cisco.com> > Sent: Wednesday, January 20, 2021 5:23 AM To: Neale Ranns <ne...@graphiant.com <mailto:ne...@graphiant.com> >; hem...@mnkcg.com <mailto:hem...@mnkcg.com> ; ayour...@gmail.com <mailto:ayour...@gmail.com> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> Subject: RE: [vpp-dev] classifier howto? Maybe the 1st question should be what is your usecase here? What is the 64-bits used for? It would be better to rely on the already-existing u32 opaque_index instead. If you really need a u64 value, you can always get away with it by using a pool of u64 values indexed by opaque_index, and look up the 64-bits value via pool_elt_at_index(p, opaque_index) in the dataplane. Best ben > -----Original Message----- > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io> > On Behalf Of Neale > Ranns > Sent: mercredi 20 janvier 2021 10:18 > To: hem...@mnkcg.com <mailto:hem...@mnkcg.com> ; ayour...@gmail.com > <mailto:ayour...@gmail.com> > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] classifier howto? > > Hi Hemant, > > > > I’ll be a little more direct 😊 you can’t expand the size of opaque. > The blast radius of such a change is just too large. > > Your alternative choices are: 1) use oqaque2, 2) overlay your ‘value’ > field in the union in opaque. The latter is preferable since you won’t > incur the cost of loading the other cacheline, but you will need to be > sure that the value remains valid (i.e. is not overwritten) by > intermediate nodes from the time it is set to the time it is used. > > > > /neale > > > > > > > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io> > on behalf of hemant > via lists.fd.io <http://lists.fd.io> <hemant=mnkcg....@lists.fd.io > <mailto:mnkcg....@lists.fd.io> > > Date: Wednesday, 20 January 2021 at 02:51 > To: ayour...@gmail.com <mailto:ayour...@gmail.com> <ayour...@gmail.com > <mailto:ayour...@gmail.com> > > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io> > > Subject: Re: [vpp-dev] classifier howto? > > Andrew, > > > > The good thing with the code changes are that the changes are common > to any plugin or base code tests. Any CSIT testing could take the > diffs and test for sanity. > > > > I also wonder when the opaque2 member (line of code below) was added > to vlib_buffer_t the cache line got impacted by a factor larger than > 2 to 3 cache lines of these changes. > > > > https://github.com/FDio/vpp/blob/5c1e48c01b50ddbd7623228e3dbc94d835d23 > 813/ > src/vlib/buffer.h#L170 > > > > Anyone recall the perf changes with opaque2? > > > > For my traffic setup (uses trex and 10G NICs) and a UPF IPv4 test, I > don’t see appreciable difference testing traffic with our without the > code changes. > > > > Thanks, > > > > Hemant > > > > From: Andrew 👽 Yourtchenko <ayour...@gmail.com <mailto:ayour...@gmail.com> > > Sent: Tuesday, January 19, 2021 6:21 PM > To: hem...@mnkcg.com <mailto:hem...@mnkcg.com> > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] classifier howto? > > > > the further discussion to be held in 30844 with the corresponding > SMEs, but in my cursory virw it’s tweaking the buffer metadata area > which is quite erformance critical - and if I read well > https://gerrit.fd.io/r/c/vpp/+/30844/2/src/vlib/buffer.h#194 increases > the per-buffer metadata size from 2 to 3 cache lines... what is the > performance impact of this change for all of the existing functions? > (Might make sense to proactively include this analysis into 30844, > since I’d expect it the very first question to be asked during the review). > > > > --a > > > > > > > On 20 Jan 2021, at 00:06, hem...@mnkcg.com <mailto:hem...@mnkcg.com> > <mailto:hem...@mnkcg.com <mailto:hem...@mnkcg.com> > > wrote: > > > > Andrew, > > > > Sorry, I am used to github which auto-merges two commits and missed > using gerrit ‘s –amend in my 2nd commit. I did what you unicasted to > me and now the latest diffs are available in review. > > > > https://gerrit.fd.io/r/c/vpp/+/30848 > > > > thanks, > > > > Hemant > > > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <vpp- > d...@lists.fd.io <mailto:d...@lists.fd.io> <mailto:vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io> > > On Behalf Of Andrew > Yourtchenko > Sent: Tuesday, January 19, 2021 4:40 PM > To: hem...@mnkcg.com <mailto:hem...@mnkcg.com> > <mailto:hem...@mnkcg.com <mailto:hem...@mnkcg.com> > > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > Subject: Re: [vpp-dev] classifier howto? > > > > > > > > > > > > On 19 Jan 2021, at 22:17, hem...@mnkcg.com > <mailto:hem...@mnkcg.com> <mailto:hem...@mnkcg.com <mailto:hem...@mnkcg.com> > > > wrote: > > > > Andrew, > > > > Great suggestion – thanks. I updated the code after taking > care of > your comments. > > > > https://gerrit.fd.io/r/c/vpp/+/30848/1 > > > > Seems like you pushed two different changes - the better approach is > to reuse the “Change-ID: xxxx” value from the previous edit by doing > “git commit —amend”, then the edits show up as the revisions of the > same change. (Which, while being a bit counterintuitive at first, > makes the gerrit workflow more powerful than eg GitHub). > > > > —a > > > > > > > > > > > > I didn’t update classify.api and classify_api.c for the > “Fancy_new_call” yet. In another Pull Request (PR), I’d like to > develop a new plugin that uses the classify entry’s value and write > packet tests etc. > > > > Cheers, > > > > Hemant > > > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <vpp- > d...@lists.fd.io <mailto:d...@lists.fd.io> <mailto:vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io> > > On Behalf Of Andrew > Yourtchenko > Sent: Tuesday, January 19, 2021 2:05 PM > To: hem...@mnkcg.com <mailto:hem...@mnkcg.com> > <mailto:hem...@mnkcg.com <mailto:hem...@mnkcg.com> > > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > Subject: Re: [vpp-dev] classifier howto? > > > > Meta-comment: > > > > old_boring_call(foo) { > > /* meat */ > > } > > > > => > > > > Fancy_new_call(foo, bar) { > > /* new meat */ > > } > > > > Old_boring_call(foo) { > > Fancy_new_call(foo, 0); > > } > > > > This way you don’t have to patch umpteen unrelated places. > > --a > > > > > > > > > On 19 Jan 2021, at 19:26, hemant via lists.fd.io > <http://lists.fd.io> > <hemant=mnkcg....@lists.fd.io <mailto:mnkcg....@lists.fd.io> <mailto:hemant > <mailto:hemant> =mnkcg....@lists.fd.io <mailto:mnkcg....@lists.fd.io> > > > wrote: > > > > Yay, I issued my first code review for VPP using gerrit > for the > issue of this email! > > > > https://gerrit.fd.io/r/c/vpp/+/30844 > > > > The JIRA issue I filed today is at: > https://jira.fd.io/browse/VPP-1967 > > > > Thanks all for replying. > > > > Hemant > > > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > <vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > On Behalf Of > hemant via lists.fd.io <http://lists.fd.io> > Sent: Monday, January 18, 2021 8:41 PM > To: hem...@mnkcg.com <mailto:hem...@mnkcg.com> > <mailto:hem...@mnkcg.com <mailto:hem...@mnkcg.com> > ; vpp- > d...@lists.fd.io <mailto:d...@lists.fd.io> <mailto:vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io> > > Subject: Re: [vpp-dev] classifier howto? > > > > Please see this PR to fix what I need. > > > > https://github.com/FDio/vpp/pull/33 > > > > Please review – thanks. > > > > Hemant > > > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > <vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > On Behalf Of > hemant via lists.fd.io <http://lists.fd.io> > Sent: Monday, January 18, 2021 10:52 AM > To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > <mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > Subject: [vpp-dev] classifier howto? > > > > I am used to the bihash’s easy to understand key-value > pair API to > program an entry for table lookup using the hash. > > > > > https://github.com/FDio/vpp/blob/master/src/vppinfra/bihash_48_8.h#L > 39 > > > > The value in the struct is a u64. > > > > To see how I program a classifier entry for use by the > data plane, > I looked at the classifier entry data structure: > > > > > https://github.com/FDio/vpp/blob/master/src/vnet/classify/vnet_class > ify.h#L66 > > > > The data structure uses a “u32x4 key[0];” key, but > where is the > value? I am used to seeing a key and value in an entry. > > > > Is “u32 opaque_index” the value? > > If yes, why does bihash use a “u64” for value but the > classifier > uses a u32? > > If the classifier table is hit, my next_node needs the > “value” > associated with the key that incurred the table hit. After all, for > bihash, e.g., clib_bihash_search_48_8() API returns an explicit value. > > > > I plan to use the API in > vnet_classify_add_del_session() to program > ip4 and ip6 src and dst address prefix matching. > > > > Thanks, > > > > Hemant > > > > > > > > > > > > > > > > > -- Andreas Schultz -- Principal Engineer t: +49 391 819099-224 ------------------------------- enabling your networks ----------------------------- Travelping GmbH Roentgenstraße 13 39108 Magdeburg Germany t: +49 391 819099-0 f: +49 391 819099-299 e: i...@travelping.com <mailto:i...@travelping.com> w: https://www.travelping.com/ Company registration: Amtsgericht Stendal Managing Director: Holger Winkelmann Reg. No.: HRB 10578 VAT ID: DE236673780
smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18568): https://lists.fd.io/g/vpp-dev/message/18568 Mute This Topic: https://lists.fd.io/mt/79925983/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
