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 C67F7A034E; Wed, 9 Feb 2022 16:34:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ACAF241144; Wed, 9 Feb 2022 16:34:13 +0100 (CET) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by mails.dpdk.org (Postfix) with ESMTP id 0246841144 for ; Wed, 9 Feb 2022 16:34:11 +0100 (CET) Received: by mail-ot1-f41.google.com with SMTP id g19-20020a9d6213000000b005ab7489371aso1766406otj.6 for ; Wed, 09 Feb 2022 07:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GOBmHbPM+qW5nRTXdeO0ctX968Ez9ZhMj61bEDIczfg=; b=MR+qtN0vyhnqCeSv6VPO8JU0Hy8A6FanB+xMLQstP441T7h/EoZNNVd5lqydP5PE0R +/cjI/rufMXvSyemF9LLrrn5RElT42roXXQgnkgI4Kmppk/Nj+Xe/9LAz+QRwxy3ozil U0uAOLQf5yV93vjzXI8dWAiii+v6iAYqkbdj8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GOBmHbPM+qW5nRTXdeO0ctX968Ez9ZhMj61bEDIczfg=; b=tsDB+0pb2r1J29zpK2cwNnua/O6kX2UCAzSw0745rf6JcPokrx7wAJ2y44tksaoNhZ McfiFfMrhoez7uh/fk3XNSbYyDAotoiEj+u8nr3hMH1oPQqb9XTYNABhLhz06+r7wkxX yTMBO0m3lykXRbyGogeDGQE+LJaW2+EauwVcloAuhX0WNobW80Lwe8zFWW2EkUEG5Ei9 EduUlJELWpg4OTgCVZqyAtSly9A8ISRtr7K+pZ7Zha0ArtVo7GbgG/V3Zx57EkfeP4NC mvCBKV7fyz7B7Z6DQaID3xA1sMhO1qBDr19bjnslK/7RFbstIXKZcwUhed5tFyNvbib9 h9HA== X-Gm-Message-State: AOAM530gxSAgVY1sOJ/5pVRw+0IGfPLk8+p6C3WRSrFwq/PBw8AYRAzC AXmoOddJTV2DF5nlzWcFYYLHlzfLN4UpjowoU3ehGg== X-Google-Smtp-Source: ABdhPJwMROwXyMEPnz4UFAW3HUlB1bq2DPMTXiexLY7/oTuDh/76kKep+wQla1CzEyRRUPigDNGYnqKGnhFIb+WfQas= X-Received: by 2002:a05:6830:310b:: with SMTP id b11mr1117816ots.322.1644420850928; Wed, 09 Feb 2022 07:34:10 -0800 (PST) MIME-Version: 1.0 References: <5238984.Sb9uPGUboI@thomas> In-Reply-To: <5238984.Sb9uPGUboI@thomas> From: Owen Hilyard Date: Wed, 9 Feb 2022 10:33:35 -0500 Message-ID: Subject: Re: [RFC] Testpmd Maintenance affecting DTS To: Thomas Monjalon Cc: dts@dpdk.org, dev , ci@dpdk.org, rasland@nvidia.com Content-Type: multipart/alternative; boundary="000000000000ae644d05d797906f" 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 --000000000000ae644d05d797906f Content-Type: text/plain; charset="UTF-8" > > Yes, any feature in ethdev should have a testpmd entry. > Which part of rte_flow is not testable with testpmd? > In general, any device API should be testable with the app/ directory. There are currently a lot of fields that appear in the documentation for rte_flow that are not exposed in testpmd. For example, 5/9 fields in ARP_ETH_IPV4 are not exposed via testpmd. I could compile a full list if you want me to. Please could you elaborate how [a parser generator] would work? Instead of the current approach of hand-rolling a parser, something like Yacc (Yet Another Compiler Compiler) or Bison (GNU Yacc) could be used to make adding new items much easier. Although they are both designed to aid in creating compilers, they also work very well as parsers which output a parsed structure. When I used Bison in the past to write an AWK implementation, what I did is have it return a struct. In the case of testpmd, an array of a tagged union might be easier to handle, so you'd get something like this back: [ { type: ITEM_ETH, inner: { eth: { dst_is_present: true, dst: "00:00:5e:00:53:af", src_is_present: true, src: "00:00:5e:00:53:af", type_is_present: false, type: 0 } } }, { type: ITEM_IPV4, inner: { ipv4: { dst_is_present: true, dst: "127.0.0.1", src_is_present: true, src: "127.0.0.1", } } } ] Once you have the tagged union and the inner structs set up, adding a new field or item should be fairly easy. Also, the _is_present could be replaced with specified "not present" values (NULL for strings, etc), this is just emulating the Option/Optional type from higher-level languages more directly. The process for adding a new field would involve first adding it to the bison grammar, then adding the field to the output struct. Why do you need RPC when a binding is generated? I guess that this is two ideas. First, have C expose an XMLRPC api. How hard this would be to do would depend greatly on the availability and quality of libraries, and it would add a fairly large dependency to this proposed app. The other idea is to generate Python bindings and then use the RPC server built into Python. This might make adding the RPC layer easier, and it would mean that we could more easily send Python types to the DUT. I think that the second one might be easier to work with, if a bit slower. performance is not good All of the performance-sensitive things, like packet generation, would still be happening entirely in C code. Also, the last time I profiled DTS it spent most of its time inside of the SSH library, so moving to Python RPC API may still increase performance, although not as much as a C RPC API. A good chunk of the rest of the time was spent either in timed performance tests (nic_single_core_perf) or waiting for testpmd to start up. > it is testing a binding, not the real API Python was built to be glue code for C libraries, so it has a very mature ecosystem in that area. If we use well-tested binding generators, then most of the underlying behavior would still be DPDK. As is, DTS doesn't really test DPDK directly, it tests testpmd, and assumes that testpmd interacts with DPDK correctly. Making a Python RPC API or Python Bindings would mean moving from a human-oriented API wrapper to a machine-oriented one. > it is a huge maintenance effort for everybody I am not advocating hand-writing Python bindings, that would be way too much work. I am advocating using a binding generator like SWIG to consume high-level DPDK header files and create python modules from them. Once this is set up, it should only need occasional maintenance due to build system changes. It might still require some work to plug new stuff into the RPC framework, but that would probably be about the same amount of work as adding the features to testpmd. I am also open to using languages other than Python, it's just that C strikes me as a bad choice for building something like this. It's possible that we could make use of gRPC or something similar that is designed to perform cross-language RPC easily, in which case directly exposing RPC in C might be much easier. Owen Hilyard --000000000000ae644d05d797906f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, any feature in ethdev should have a testpmd entry.
Which= part of rte_flow is not testable with testpmd?

In general, any device API should be testable wi= th the app/ directory.

=C2=A0There are curr= ently a lot of fields that appear in the documentation for rte_flow that ar= e not exposed in testpmd. For example, 5/9 fields in=C2=A0ARP_ETH_IPV4 are = not exposed via testpmd. I could compile a full list if you want me to.=C2= =A0

P= lease could you elaborate how [a parser generator] would work?
=

=C2=A0Instead of the current approach of hand-rolling a= parser, something like Yacc (Yet Another Compiler Compiler) or Bison (GNU = Yacc) could be used to make adding new items much easier. Although they are= both designed to aid in creating compilers, they also work very well as pa= rsers which output a parsed structure. When I used Bison in the past to wri= te an AWK implementation, what I did is have it return a struct. In the cas= e of testpmd, an array of a tagged union might be easier to handle, so you&= #39;d get something like this back:
= [
=C2=A0 {
=C2=A0 =C2=A0 type: ITEM_ETH,
=C2=A0 =C2=A0 inner: {=C2=A0 =C2=A0 =C2=A0 eth: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dst_is_present:= true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dst: "00:00:5e:00:53:af",=C2=A0 =C2=A0 =C2=A0 =C2=A0 src_is_present: true,
=C2=A0 =C2=A0 =C2=A0= =C2=A0 src: "00:00:5e:00:53:af",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = type_is_present: false,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type: 0
=C2=A0 = =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 },
=C2=A0 {
=C2=A0 =C2= =A0 type: ITEM_IPV4,
=C2=A0 =C2=A0 inner: {
=C2=A0 =C2=A0 =C2=A0 ipv4= : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dst_is_present: true,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 dst: "127.0.0.1",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sr= c_is_present: true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 src: "127.0.0.1&quo= t;,
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
]

Once you have the tagged union and the inner structs set up, add= ing a new field or item should be fairly easy. Also, the <field>_is_p= resent could be replaced with specified "not present" values (NUL= L for strings, etc), this is just emulating the Option/Optional type from h= igher-level languages more directly. The process for adding a new field wou= ld involve first adding it to the bison grammar, then adding the field to t= he output struct.=C2=A0

Why do you need RPC when a binding is gene= rated?

I guess that this is=C2=A0two ideas.= First, have C expose an XMLRPC api. How hard this would be to do would dep= end greatly on the availability and quality of libraries, and it would add = a fairly large dependency to this proposed app. The other idea is to genera= te Python bindings and then use the RPC server built into Python. This migh= t make adding the RPC layer easier, and it would mean that we could more ea= sily send Python types to the DUT. I think that the second one might be eas= ier to work with, if a bit slower.=C2=A0

performance is not good

All of the performance-sensitive things, like packet = generation, would still be happening entirely in C code. Also, the last tim= e I profiled DTS it spent most of its time inside of the SSH library, so mo= ving to Python RPC API may still increase performance, although not as much= as a C RPC API. A good chunk of the rest of the time was spent either in t= imed performance tests (nic_single_core_perf) or waiting for testpmd to sta= rt up.
=C2=A0
it is testing a binding, not the real API

Python was built to be glue code for C libraries, so it has a very matur= e ecosystem in that area. If we use well-tested binding generators, then mo= st of the underlying behavior would still be DPDK. As is, DTS doesn't r= eally test DPDK directly, it tests testpmd, and assumes that testpmd intera= cts with DPDK correctly. Making a Python RPC API or Python Bindings would m= ean moving from a human-oriented API wrapper to a machine-oriented one.=C2= =A0
=C2=A0
it is a huge maintenance effort for everybody

<= div>I am not advocating hand-writing Python bindings, that would be way too= much work. I am advocating using a binding generator like SWIG to consume = high-level DPDK header files and create python modules from them. Once this= is set up, it should only need occasional maintenance due to build system = changes. It might still require some work to plug new stuff into the RPC fr= amework, but that would probably be about the same amount of work as adding= the features to testpmd.=C2=A0

I am also op= en to using languages other than Python, it's just that C strikes me as= a bad choice for building something like this. It's possible that we c= ould make use of gRPC or something similar that is designed to perform cros= s-language RPC easily, in which case directly exposing RPC in C might be mu= ch easier.=C2=A0

Owen Hilyard
--000000000000ae644d05d797906f--