Re: [RFC] Testpmd Maintenance affecting DTS

[Owen Hilyard <ohilyard@iol.unh.edu>]

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

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

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