There are 2 separate issues

>From your example:

def create_stream(self, src_if):
    """Create input packet stream for defined interface.
    :param VppInterface src_if: Interface to create packet stream for.
    """
    good_request = (Ether(dst=src_if.local_mac, src=src_if.remote_mac) /
                    IP(src=src_if.remote_ip4) /
                    UDP(sport=1234, dport=53) /
                    DNS(rd=1, qd=DNSQR(qname="bozo.clown.org")))

    bad_request = (Ether(dst=src_if.local_mac, src=src_if.remote_mac) /
                    IP(src=src_if.remote_ip4) /
                    UDP(sport=1234, dport=53) /
                    DNS(rd=1, qd=DNSQR(qname="no.clown.org")))
    pkts = [good_request, bad_request]
    return pkts

Why do we generate this at runtime?  Create the packet stream once at test
development, not at runtime, every time the test is run.
Scapy is for python and is licensed gpl and requires the tests to be
licensed as gpl due to the imports.
libpnet is a rust crate and licensed MIT/Apache2.  If the packet is read as
a .pcap file, we have no licensing issues with packet creation and the test
creator is free to use whatever tool he/she chooses to craft the packet.
It also reduces the work to move to a different language for testing if
someone wishes to.

Dave Barach has shown, more than once on this list, how a packet can be
created from a text file by the vpp packet generator.  My point is that we
have options.

I agree, python review *should be* possible.  These are the same folks that
Andrew asserts should be the owners of the python tests.

Why are jvpp and govpp separate projects but vpp_papi requires someone to
have to download the sources?  Yes, there is a 3 year old package on pypi
[0], but it does not work on any supported version of VPP.  Python users
want to do python3 -m pip install vpp_papi and go.  Even if someone didn't
want to cut official releases, if it were stand alone, folks could use any
version they chose with just pip.  If folks want it in the source tree, use
a submodule.  We have the skillset in house. Florin does that in [1].

Paul

[0] https://pypi.org/project/vpp-papi/
[1] https://github.com/FDio/vsap

Paul

On Tue, Mar 30, 2021 at 3:40 PM <hem...@mnkcg.com> wrote:

> Doesn’t take much to find a Python example that uses vapi.  See
> https://github.com/FDio/vpp/blob/master/src/plugins/dns/test/test_dns.py
>
>
>
> What is wrong with using Scapy to specify packets that pcap or libpnet is
> being discussed?
>
>
>
> There is also lua and Snabb:  https://github.com/snabbco/snabb
>
>
>
> I suspect more engineers know Python than golang or rust, so code review
> should be possible.
>
>
>
> Hemant
>
>
>
> *From:* Paul Vinciguerra <pvi...@vinciconsulting.com>
> *Sent:* Tuesday, March 30, 2021 12:00 PM
> *To:* hem...@mnkcg.com
> *Cc:* Damjan Marion <dmar...@me.com>; Dave Wallace <dwallac...@gmail.com>;
> vpp-dev <vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] keeping tests outside of src/
>
>
>
> Hi Damjan,
>
>
>
> Funny you say that.  I *have* been looking into exactly that.  The issue
> is that the library ecosystem is scarce.  I have actually started adding
> some of our protocols to the libpnet crate to see if it is viable.
>
>
>
> #[packet]
>
> pub struct Snap {
>     #[length="3"]
>     org_code: Vec<u8>,
>     ethertype: u16be,
>     #[payload]
>     data: Vec<u8>,
> }
> #[test]
> fn test_llc_builder() {
>     let mut buff = [0; 3];
>     let mut l = MutableLlcPacket(&buff);
>     l.set_dsap(0xaa);
>     l.set_ssap(0xbb);
>     l.set_control(3);
>     assert_eq! (buff, [0xaa, 0xbb, 3]);
> }
>
> I don't think it is viable to move to for tests yet, but it has promise
> and the licensing of libpnet is promising.  I would support moving to it,
> but there are some of the same issues that need to be addressed.
>
> If we move the packet creation to saved .pcap files, it facilitates moving
> tests to another language or framework.
> Some of the tests rely on external python packages today, presumably
> because the developer did not want to roll the code on their own.  Moving
> to a new language needs to address that.  The problems that exist with the
> tests is that imperative rules are forced on the test developers. Move
> configuration of VPP to a declarative mechanism and let the test developers
> focus on the action they wish to test.
>
> I see no issue with python as a language.  I see issues with how the group
> used python.  Compare/contrast the python use in /test to that of CSIT.
> The CSIT code is orders of magnitude better in my opinion.  Clean
> interfaces, proper documentation. Kudos to them.
>
> I don't care that the tests are in python. I care that there is an example
> of how to implement VPP in python, because it is, for the time being, the
> lingua franca of the netdevops world.  As it exists today, however, it is
> really not usable.  The majority of the tests use vpp_<foo> objects to
> isolate consumers from the shortcomings of the api from a consumer's
> perspective.
>
> If you embrace Andew's position that the component maintainer "own's" the
> tests for that component, maybe we should embrace it fully.  Let the
> maintainer write the test code in any language they choose.
>
> There is a whole spectrum of options available.  I'm not against rust.  I
> have also been asked about moving the tests to go.  My opinion is the same.
> The issues around tests exist irrespective of the language.  As a
> maintainer of /test, the most frequent response I received is that "I don't
> know python enough to review your change". How does moving to
> rust/golang/<lang of the day> address that?
>
> Is the problem that the tests are written in python, or that the tests
> rely on papi, or that python vpp_objects are written in python to replace
> vom?  They're all considerations if we're thinking about starting over.
>
> Paul
>
>
>
> On Mon, Mar 29, 2021 at 7:45 PM <hem...@mnkcg.com> wrote:
>
> Hmm, most folks have moved from Python to Golang, not Rust.  Rust is
> better suited to replace C for data plane programming.
>
>
>
> Hemant
>
>
>
> *From:* Damjan Marion <dmar...@me.com>
> *Sent:* Monday, March 29, 2021 4:27 PM
> *To:* Paul Vinciguerra <pvi...@vinciconsulting.com>
> *Cc:* hem...@mnkcg.com; Dave Wallace <dwallac...@gmail.com>; vpp-dev <
> vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] keeping tests outside of src/
>
>
>
>
>
> Dear Paul,
>
>
>
> I think we should stop using python and move to rust :)
>
>
>
> —
>
> Damjan
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19063): https://lists.fd.io/g/vpp-dev/message/19063
Mute This Topic: https://lists.fd.io/mt/81611239/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to