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 (#19061): https://lists.fd.io/g/vpp-dev/message/19061
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]
-=-=-=-=-=-=-=-=-=-=-=-
