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 A5BA143B3E; Wed, 14 Feb 2024 18:27:25 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 429F5432DC; Wed, 14 Feb 2024 18:27:25 +0100 (CET) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2074.outbound.protection.outlook.com [40.107.243.74]) by mails.dpdk.org (Postfix) with ESMTP id 3DEA642DED; Wed, 14 Feb 2024 18:27:23 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GoBl/BaspBene07keUUbceu+1j9exSBd7kS/HYxvZa2iyhRBRPM0icY2FXXsp4a9AmB/J5fTAuJKfl6CPJALMp6w1mFmcoM5LhDo9zoqz800jB+h2bTW9ck5Sy4JqIFL/+0cNG16xYWbP77DWBVH/PTwH6JShRQuk6P/gwyFWE/5aVo3UYt5mQ/E2h1zmCuJVCclJXVoheBy/gWHX5FE4tRhOLvy0KEiZuMs00xAn8wg5fWN+eoxatMvFYiaLxCHs/CUBVSVUjAe53MAmxkFccKMGgpj8hNUTguPMMBxoaX5GxgNfqz/gXkJ8tuhw7xxfrwMJQ7uY5AOsJOU5XqY7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xs9IOijjlBVVazsFJUr3pyoHRR3jnIB0BKUMPwmEYlI=; b=bvHZOwJQkGb3sgV/+fsRiyARtAqPjgqcSwv3C4lkAwChPc2S9XBtdAJSo0kzGvhpQSKJ5/Kz7wGUV8DG/YWQVKxfBQczlJjyKOb52ipRf7MYU+Cf1p+OUAr4JyhW2KlWLF5jCPxgW1KSJo+nz0ux4GIWRd+D3dUcP8xEP1zEBczWUoE0Qgxs66MVrWwZ/XpmRthdtiadrxCwcjDDJuG5qzsiG1Tmu5lhV2HP6y60244E5sT9nKLkHEKsckQ8XxFVbNdORhVS7vZTNRvJ50+7rwa9u/0vDQrORCkYpZnSCl4p+TMji1SiZKOllvyMZkM90sNc9YbJm+zhVuuLM0U2Pw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xs9IOijjlBVVazsFJUr3pyoHRR3jnIB0BKUMPwmEYlI=; b=EV4sLRmLhF4vjEwwFHn4w39A1h3SWV3OGS9jB9fDkXzhMsjkxwuzJaPwLnyi3LDLOzh5s9NvW0Bt0gVst7pP1wbbFJu1fBF3Qsen/YEwV3N2p7okjw2v2QaCzpx8OAsXi2lHWpCVXDGlFXvfVBzdFRuPdMSVYf6Lkxdn2bWimHdlqcL/LXoAk5EaJYNWjldWqoNfyFgi9etoXLQVpvEIhe0VyiATg/50Jp0m+W+AABVeEZrnRQVLAXzpzdazp8aLrDDTRK4P/9kFtIRJ4/CzAt1LoRWWpbto2nlPNU5pN8NFui4lB2ztP8Vy1XrGvlCjz1O6K9r1/ApXspbrhHLrfQ== Received: from IA1PR12MB6332.namprd12.prod.outlook.com (2603:10b6:208:3e2::13) by CY8PR12MB7291.namprd12.prod.outlook.com (2603:10b6:930:54::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.26; Wed, 14 Feb 2024 17:27:20 +0000 Received: from IA1PR12MB6332.namprd12.prod.outlook.com ([fe80::22fc:4326:d657:92ad]) by IA1PR12MB6332.namprd12.prod.outlook.com ([fe80::22fc:4326:d657:92ad%7]) with mapi id 15.20.7292.013; Wed, 14 Feb 2024 17:27:20 +0000 From: Gregory Etelson To: Patrick Robb CC: Jeremy Spewock , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Honnappa Nagarahalli , =?Windows-1252?Q?Juraj_Linke=9A?= , Paul Szczepanek , Yoan Picchi , Luca Vizzarro , "ci@dpdk.org" , "dev@dpdk.org" , nd , Maayan Kashani , Asaf Penso Subject: Re: DTS testpmd and SCAPY integration Thread-Topic: DTS testpmd and SCAPY integration Thread-Index: AQHaN82Y1xzKJvsNjkuGHOCbKSfihrDP564AgBZagICAAKqQgIAAVg6AgAChDACAB4sDLIADsbqAgACiBwCAFqM2mA== Date: Wed, 14 Feb 2024 17:27:20 +0000 Message-ID: References: <2a287ee7-cda4-f2ab-a4e6-a47021f8573f@nvidia.com> <2127794.bB369e8A3T@thomas> <6608561.G0QQBjFxQf@thomas> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: IA1PR12MB6332:EE_|CY8PR12MB7291:EE_ x-ms-office365-filtering-correlation-id: 669e78d3-35bc-41ef-f1ff-08dc2d823310 x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4X5Gur6c3YKYBZWT6yEaR9nr2CgG6VwBab5nQfzBmMg3uHLjD1pFN2Ajby+lpggnD6I5RKaMOajUbwsPs7kZTLEyEyjsy0I77zfRlE+ntQIWMmlpIDjbmwTNNYF0NDDQce7xENinwy7IWKiVCR/+cPkSLmS3L0fM/jyWYkgX/OhMi1eMzm3VQWMAxsAHBM6lHL4PzMD4NhtFnxoP/J2ApitVMPP7iQb41MXeHOGE2WfVtDiOmsLbMD9vgFQ32FRUkv6RVGWd9iByVkUyhKW+chWLLgMsAIFR6HtSAYbSYzid5APSg0m15ijyndCiY9YE8GIBPOYF4iR6AJKVSWeQG5MnqGRXctVUlVIi07jBW8qeVliaMinie9RK9uGKbQ85l1VzSUioXvvhf50d5s9CuO9E139DBeXBdVRvybqFS1qlD5c+kJLoL3IFrmorM6Uuv6bsUR4kcdWtPDruB9HS3NBs+OjTT0JK7Tdh+9K2OwpUb9ldGWb4eJFsoH9Hh+uquChalh9eTKpGEBCfyiFp9GGj1Qdgc8xJCu0jsARPu8YRXwoLfPP19+6UPtQHDs0cAwErxwfpeDFanGEklXVQDw7S0mqmTByGW6pygY3bmxbLY8feAmQfb4o8wHifzUPNCTx128lccJkxs19LCtP+PkU38rJpdB/RqE9d7Banu8L/cEwst0PcQfJ7yYrPtRPKW+ewJLO8Qo5l2EqLrmcj9baDgrrxZvHGIsfzmrjceE+a5VCiAQEZnO1T6+a7crUehtJa1tzkRTBVvmzNlEn3Y0YA9vb9NrG0PZvTvTuJyUhehCP9gXSp9EN7ySnG/nWbc0BWXXjNDsHjfiumGyxWzsyS2qO6AC8/lnK+0KQ/7D9gBk8rKjTAVQfQEdod0AYquWO12YSkqDhG/ZUr7GM2WzwtYubZNF9i1rh4S+L71oTTZKQnKjBlpap2LInNeJg0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR12MB6332.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(346002)(396003)(39860400002)(376002)(136003)(230273577357003)(230922051799003)(451199024)(64100799003)(186009)(1800799012)(83380400001)(86362001)(41300700001)(1015004)(107886003)(316002)(54906003)(6916009)(2906002)(53546011)(9686003)(7696005)(33656002)(71200400001)(64756008)(6506007)(38070700009)(66556008)(7416002)(5660300002)(478600001)(8936002)(66476007)(76116006)(66946007)(91956017)(4326008)(66446008)(8676002)(21615005)(52536014)(38100700002)(55016003)(19627405001)(122000001)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?nKCwZR2RU1ui96HPdHYPltQJB1vyyEMCF9i8tBwNUIsC1/X8S3Gqh4O9?= =?Windows-1252?Q?BjpIyCA8luYrw3OWDxLLqhNwP67pZ2bY7zHibLf+YFaYEOZmMnW/gKPS?= =?Windows-1252?Q?ayPjiQXsVzxslMUbQHLRvxNg61G0EBN5JeHdRS1TxsRohVJMZrijODEW?= =?Windows-1252?Q?ET8SCX0o0CeLyCdLZZTuC1gB1AlgHRub3pUSBI/e6BcyuM1SWxUOY/Ed?= =?Windows-1252?Q?OaUEztxeguhYG7mo8/hsW7MG06aied3qq7mfHgNyekzVrJHfC00y3/f3?= =?Windows-1252?Q?XSfjpNbyZyoLMT77ABEjdVZaqyzwbrwcIfqkXUin+xuPkV8oMfZ4Srfn?= =?Windows-1252?Q?3NvHkrZ/k+KVycpcgORNCGF9RGcWtEIHO0j+JnHLswEyrPUBmIRQwE2Z?= =?Windows-1252?Q?RWPT5clWRhZmuHfNU02Ke35QjK22/pj81GWWBqszsscwqrkfB9qKUi8k?= =?Windows-1252?Q?gmwDeM1bRqG6uItD11ERp8HY2UQjzJ+VU5UHfvOmFdwnfYIPYvgYow/c?= =?Windows-1252?Q?3jjJ1ap4noLK5t1URZ9ycmu43DEDp0DCbUYtFsTWM6GRShXfvexOflSQ?= =?Windows-1252?Q?gelhHOUn2QzTcZdNQl1ByVmLfXFb4NFhYrAOrAXIUTgzmrpQFbDcEWxS?= =?Windows-1252?Q?O3Wph+v9T8FnW3aXHXcb8MkoUDkNUe0rHXN+nqhoxKxfnYiR3m8BGzJu?= =?Windows-1252?Q?cEkUARN72ysUWxJHD8lArpaNK/5xsSqHUlv933ohvDxYYs4GGS8Rj2h2?= =?Windows-1252?Q?exS6j6LumhMQwP/RX6O5fHjG4y9UNPN4ppegWEw6ORHZW3bNgbq5psLh?= =?Windows-1252?Q?jR2FTHrZTnKQBdDd3gpGhlqAlV3FdSFEXJzY5u5PeNWpduAN7Rx4Fe5Q?= =?Windows-1252?Q?gW95DTIF0xhxZbKKAhpYoMz6Tn9IlloYvBngULiufNUOgIE9dnGT6Zlk?= =?Windows-1252?Q?uz83Pr7G4Vt3L8iyC8fFN0zuz47u61E6uNKbdA+cYRhakeajCkLe+82Q?= =?Windows-1252?Q?qOZmvLSAwoqlmMcujDuMQ5KVip3rEa2sSWAOIU60FaRtdaT7aPrmUQOF?= =?Windows-1252?Q?ibiDoLSzy23+g7v8Kw2i5+mI5i3pqU/PV1e4RMZ5d/R0kos4ZbwWqAcL?= =?Windows-1252?Q?L90lpns199h8q3AB36FClD9DSafg1FcyqvX0TJ+EHARTU3MZpR0cS4AB?= =?Windows-1252?Q?P3ApfAOvLo0OYat0IvRkfB1Me9ZQtu5iOJyKNOMP8e7KHNgHf+1VEsNs?= =?Windows-1252?Q?IA2OVasVHYn/MmNKGdcnegUFbUXacUyIkne+m8Yz0xAhKtgtKmSIsKPn?= =?Windows-1252?Q?wI6jOLEnZddNPnL4hLKU6jkFCsT/BpT4lMszp6+GozrsN2LJA2lSPJuL?= =?Windows-1252?Q?nyMLMmhHlqTH+LS5Y0a5qIjrft8hEixJySfIDc5f8XHcBmDTyPvZ+veW?= =?Windows-1252?Q?puxk5eRor4g6mAeNMn2EEeMCsRVMeh2+BieDWMmUX3kLWJfmdibouoxQ?= =?Windows-1252?Q?OjPJ4JGTas4s2CVuRmV2d3+mCuzPClNN4l0ItyAnOu/LqeMkaYdFJHDn?= =?Windows-1252?Q?CL+IIdBNOHIN+TtFBI16iGNAc3V17zIzelwyQZT50bwzlKR2O/pD/RNS?= =?Windows-1252?Q?1AbcumphDv+wnXvqXhIMs2oOYZK0Tim3Mmghe4DV4/g7qj880QbyU+0C?= =?Windows-1252?Q?0e1AZCvP6X5Eq0HQSW6yfFHzmmc2GvtLhTLVTcYi5yOARHSpLh4dCJ8L?= =?Windows-1252?Q?OBHws7cQbIKH+hhXxc7aM7xIk70O/WMPay55vRto?= Content-Type: multipart/alternative; boundary="_000_IA1PR12MB633208BB2EAF2B85A0B376CDA54E2IA1PR12MB6332namp_" MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6332.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 669e78d3-35bc-41ef-f1ff-08dc2d823310 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2024 17:27:20.4952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0NIJwLXh/NnbBxsdrWlxV2kTtkKpnm3FUe1X14u3SYZezlGzCSDc4ch0Bb8ghFHeThwRMf+07x4trjary0rnXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7291 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 --_000_IA1PR12MB633208BB2EAF2B85A0B376CDA54E2IA1PR12MB6332namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Patrick, Did you have time to check the Unit Test design ? Do you think it can be used for short functional DTS tests ? Regards, Gregory ________________________________ From: Gregory Etelson Sent: Wednesday, January 31, 2024 09:43 To: Patrick Robb Cc: Gregory Etelson ; Jeremy Spewock ; NBU-Contact-Thomas Monjalon (EXTERNAL) ; Honnap= pa Nagarahalli ; Juraj Linke=9A ; Paul Szczepanek ; Yoan Picchi ; Luca Vizzarro ; ci@dpdk.org= ; dev@dpdk.org ; nd ; Maayan Kashan= i ; Asaf Penso Subject: Re: DTS testpmd and SCAPY integration Hello Patrick, > External email: Use caution opening links or attachments > Thank you for sharing Gregory. I did not get an opportunity to look throu= gh the code today, but I did run > through the presentation. A few points I noted: > 1. The presentation shows an example testpmd testcase for creating a flow= rule, and then shows a > validation step in which standard out is compared against the expected st= ring ("flow rule x created") and > we can conclude whether we are able to create flow rules. Are you also se= nding packets according to the > flow rules and validating that what is sent/received corresponds to the e= xpected behavior of the flow > rules? When I look at the old DTS framework, and an example flow rules te= stsuite > (https://doc.dpdk.org/dts/test_plans/rte_flow_test_plan.html) which we wa= nt feature parity with, I think > that validation for this testing framework needs to primarily rely on com= paring packets sent and packets > received. The unit test infrastructure validates flow rule creation and a result produced by that flow. Flow result is triggered by a packet. However, flow result validation does not always can be done by testing a pa= cket. Unit test implements 2 flow validation methods. The first validation method tests testpmd output triggered by a test packet= . Example: use the MODIFY_FIELD action to copy packet VLAN ID to flow TAG ite= m. Flow tag is internal flow resource. It must be validated in DPDK applicatio= n. Test creates 2 flow rules: Rule 1: use MODIFY_FILED to copy packet VLAN ID to flow TAG item pattern eth / vlan / end \ actions modify_field op set dst_type tag ... src_type vlan_id ... / end Rule 2: validate the TAG item: pattern tag data is 0x31 ... / end actions mark id 0xaaa / rss / end The test sends a packet with VLAN ID 0x31: / Dot1Q(vlan=3D0x31) / The test matches tespmd output triggered by the packet for `FDIR matched ID=3D0xaaa`. The second validation method tests a packet after it was processed by a flo= w. Unit test operates in a static environment. It does not compare source and target packets. The test "knows" valid target packet configurati= on. Example: push VLAN header into a packet. There is a single flow rule in that example: pattern eth / end \ actions of_push_vlan ethertype 0x8100 / \ of_set_vlan_vid vlan_vid 3103 .../ port_id id 1 / end There are 2 SCAPY processes in that test: `tg` runs on peer host and sends a source packet. `vm` runs on the same host as testpmd. It validates incoming packet. Phase 0 prepares test packet on the `tg` and starts AsyncSniffer on the `vm= `. Phase 1 sends the packet. Phase 2 validates the packet. The test can repeat phases 1 and 2. phase0: vm: | sniff =3D AsyncSniffer(iface=3Dpf1vf0, filter=3D'udp and src port 1234= ') tg: | udp_packet =3D Ether(src=3D'11:22:33:44:55:66', dst=3D'aa:bb:cc:dd:ee:aa')/ IP(src=3D'1.1.1.1', dst=3D'2.2.2.2')/ UDP(sport=3D1234, dport=3D5678)/Raw('=3D=3D TEST =3D=3D') phase1: &phase1 vm: sniff.start() tg: sendp(udp_packet, iface=3Dpf1) phase2: &phase2 vm: | cap =3D sniff.stop() if len(cap[UDP]) > 0: cap[UDP][0][Ether].command() result: vm: vlan=3D3103 >In any case, there may be some testsuites which can be written which are s= mall >enough in scope > that validating by standard out in this way may be appropriate. I'm not s= ure but we should keep our > options open. > > 2. If the implementation overhead is not too significant for the configur= ation step in the DTS execution a > "--fast" option like you use may be a good improvement for the framework.= In your mind, is the main > benefit A. reduced execution time, B. reduced user setup time (don't have= to write full config file) or C. > Something else? A user must always provide test configuration. However a host can already have prepared setup before the test execution. In that case a user can skip host setup phase and reduce execution time. > > Thanks for making this available to use so we can use it as a reference i= n making DTS better. :) > > --_000_IA1PR12MB633208BB2EAF2B85A0B376CDA54E2IA1PR12MB6332namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Patrick,

Did you have time to check the Unit Test design ?
Do you think it can be used for short functional DTS tests ?

Regards,
Gregory

From: Gregor= y Etelson
Sent: Wednesday, January 31, 2024 09:43
To: Patrick Robb <probb@iol.unh.edu>
Cc: Gregory Etelson <getelson@nvidia.com>; Jeremy Spewock= <jspewock@iol.unh.edu>; NBU-Contact-Thomas Monjalon (EXTERNAL) <t= homas@monjalon.net>; Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.c= om>; Juraj Linke=9A <juraj.linkes@pantheon.tech>; Paul Szczepanek <Paul.Szczepanek@arm.com>; Yoan Picchi <yoan.picchi@foss.arm.com&= gt;; Luca Vizzarro <Luca.Vizzarro@arm.com>; ci@dpdk.org <ci@dpdk.o= rg>; dev@dpdk.org <dev@dpdk.org>; nd <nd@arm.com>; Maayan Ka= shani <mkashani@nvidia.com>; Asaf Penso <asafp@nvidia.com>
Subject: Re: DTS testpmd and SCAPY integration
 
Hello Patrick,

> External email: Use caution opening links or attachments
> Thank you for sharing Gregory. I did not get an opportunity to look th= rough the code today, but I did run
> through the presentation. A few points I noted:
> 1. The presentation shows an example testpmd testcase for creating a f= low rule, and then shows a
> validation step in which standard out is compared against the expected= string ("flow rule x created") and
> we can conclude whether we are able to create flow rules. Are you also= sending packets according to the
> flow rules and validating that what is sent/received corresponds = to the expected behavior of the flow
> rules? When I look at the old DTS framework, and an example flow rules= testsuite
> (https://doc.dpdk.org/d= ts/test_plans/rte_flow_test_plan.html) which we want feature parity with, I think
> that validation for this testing framework needs to primarily rely on = comparing packets sent and packets
> received.

The unit test infrastructure validates flow rule creation and
a result produced by that flow.
Flow result is triggered by a packet.
However, flow result validation does not always can be done by testing a pa= cket.
Unit test implements 2 flow validation methods.

The first validation method tests testpmd output triggered by a test packet= .

Example: use the MODIFY_FIELD action to copy packet VLAN ID to flow TAG ite= m.
Flow tag is internal flow resource. It must be validated in DPDK applicatio= n.

Test creates 2 flow rules:

Rule 1: use MODIFY_FILED to copy packet VLAN ID to flow TAG item
pattern eth / vlan / end \
actions modify_field op set dst_type tag ... src_type vlan_id ... / end

Rule 2: validate the TAG item:
pattern tag data is 0x31 ... / end actions mark id 0xaaa / rss / end

The test sends a packet with VLAN ID 0x31: / Dot1Q(vlan=3D0x31) /
The test matches tespmd output triggered by the packet for
`FDIR matched ID=3D0xaaa`.

The second validation method tests a packet after it was processed by a flo= w.

Unit test operates in a static environment. It does not compare
source and target packets. The test "knows" valid target packet c= onfiguration.

Example: push VLAN header into a packet.

There is a single flow rule in that example:
pattern eth / end \
actions of_push_vlan ethertype 0x8100 / \
         of_set_vlan_vid vlan_vid 3= 103 .../ port_id id 1 / end


There are 2 SCAPY processes in that test: `tg` runs on peer host and
sends a source packet. `vm` runs on the same host as testpmd. It validates<= br> incoming packet.

Phase 0 prepares test packet on the `tg` and starts AsyncSniffer on the `vm= `.
Phase 1 sends the packet.
Phase 2 validates the packet.
The test can repeat phases 1 and 2.


phase0:
   vm: |
     sniff =3D AsyncSniffer(iface=3Dpf1vf0, filter=3D'u= dp and src port 1234')

   tg: |
     udp_packet =3D Ether(src=3D'11:22:33:44:55:66',             &nb= sp;           dst=3D'aa:b= b:cc:dd:ee:aa')/
            &nb= sp;     IP(src=3D'1.1.1.1', dst=3D'2.2.2.2')/
            &nb= sp;     UDP(sport=3D1234, dport=3D5678)/Raw('=3D=3D TES= T =3D=3D')

phase1: &phase1
   vm: sniff.start()
   tg: sendp(udp_packet, iface=3Dpf1)

phase2: &phase2
   vm: |
     cap =3D sniff.stop()
     if len(cap[UDP]) > 0: cap[UDP][0][Ether].comman= d()
   result:
         vm: vlan=3D3103

>In any case, there may be some testsuites which can be written which ar= e small
>enough in scope
> that validating by standard out in this way may be appropriate. I'm no= t sure but we should keep our
> options open. 
>
> 2. If the implementation overhead is not too significant for the confi= guration step in the DTS execution a
> "--fast" option like you use may be a good improvement for t= he framework. In your mind, is the main
> benefit A. reduced execution time, B. reduced user setup time (don't h= ave to write full config file) or C.
> Something else?

A user must always provide test configuration.
However a host can already have prepared setup before the test execution. In that case a user can skip host setup phase and reduce execution time.  
>
> Thanks for making this available to use so we can use it as a referenc= e in making DTS better. :) 
>
>
--_000_IA1PR12MB633208BB2EAF2B85A0B376CDA54E2IA1PR12MB6332namp_--