From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <ci-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 37F0843B3C;
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 1DBCF42E1F;
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 <getelson@nvidia.com>
To: Patrick Robb <probb@iol.unh.edu>
CC: Jeremy Spewock <jspewock@iol.unh.edu>, "NBU-Contact-Thomas Monjalon
(EXTERNAL)" <thomas@monjalon.net>, Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com>, =?Windows-1252?Q?Juraj_Linke=9A?=
<juraj.linkes@pantheon.tech>, Paul Szczepanek <Paul.Szczepanek@arm.com>, Yoan
Picchi <yoan.picchi@foss.arm.com>, Luca Vizzarro <Luca.Vizzarro@arm.com>,
"ci@dpdk.org" <ci@dpdk.org>, "dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>,
Maayan Kashani <mkashani@nvidia.com>, Asaf Penso <asafp@nvidia.com>
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: <IA1PR12MB633208BB2EAF2B85A0B376CDA54E2@IA1PR12MB6332.namprd12.prod.outlook.com>
References: <2a287ee7-cda4-f2ab-a4e6-a47021f8573f@nvidia.com>
<2127794.bB369e8A3T@thomas>
<DBAPR08MB5814F41082DD2D113FA46A5D98742@DBAPR08MB5814.eurprd08.prod.outlook.com>
<6608561.G0QQBjFxQf@thomas>
<CAAA20URwNgFq627F4evfkvF7waPpsb1rxoqd_wV-eko4QUCn6A@mail.gmail.com>
<IA1PR12MB6332E9E4BD9540479DDB943BA57F2@IA1PR12MB6332.namprd12.prod.outlook.com>
<CAJvnSUAta_e7unw2FwwJxLQYKe9H_+hJ8Fh7x+CK2Q-wTn+JUg@mail.gmail.com>
<dbb626e2-62d3-aa2f-94bf-5ae53d3a47ed@nvidia.com>
In-Reply-To: <dbb626e2-62d3-aa2f-94bf-5ae53d3a47ed@nvidia.com>
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: ci@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK CI discussions <ci.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/ci>,
<mailto:ci-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/ci/>
List-Post: <mailto:ci@dpdk.org>
List-Help: <mailto:ci-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/ci>,
<mailto:ci-request@dpdk.org?subject=subscribe>
Errors-To: ci-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 <probb@iol.unh.edu>
Cc: Gregory Etelson <getelson@nvidia.com>; Jeremy Spewock <jspewock@iol.unh=
.edu>; NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Honnap=
pa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Juraj Linke=9A <juraj.linkes=
@pantheon.tech>; Paul Szczepanek <Paul.Szczepanek@arm.com>; Yoan Picchi <yo=
an.picchi@foss.arm.com>; Luca Vizzarro <Luca.Vizzarro@arm.com>; ci@dpdk.org=
<ci@dpdk.org>; dev@dpdk.org <dev@dpdk.org>; nd <nd@arm.com>; Maayan Kashan=
i <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 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
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Hello Patrick,</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Did you have time to check the Unit Test design ?</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Do you think it can be used for short functional DTS tests ?</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Regards,</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Gregory</div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style=3D"display: inline-block; width: 98%;">
<div dir=3D"ltr" id=3D"divRplyFwdMsg"><span style=3D"font-family: Calibri, =
sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Gregor=
y Etelson<br>
<b>Sent:</b> Wednesday, January 31, 2024 09:43<br>
<b>To:</b> Patrick Robb <probb@iol.unh.edu><br>
<b>Cc:</b> 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><br>
<b>Subject:</b> Re: DTS testpmd and SCAPY integration</span>
<div> </div>
</div>
<div><span style=3D"font-size: 11pt;">Hello Patrick,<br>
<br>
> External email: Use caution opening links or attachments<br>
> Thank you for sharing Gregory. I did not get an opportunity to look th=
rough the code today, but I did run<br>
> through the presentation. A few points I noted:<br>
> 1. The presentation shows an example testpmd testcase for creating a f=
low rule, and then shows a<br>
> validation step in which standard out is compared against the expected=
string ("flow rule x created") and<br>
> we can conclude whether we are able to create flow rules. Are you also=
sending packets according to the<br>
> flow rules and validating that what is sent/received corresponds =
to the expected behavior of the flow<br>
> rules? When I look at the old DTS framework, and an example flow rules=
testsuite<br>
> (<a href=3D"https://doc.dpdk.org/dts/test_plans/rte_flow_test_plan.htm=
l" data-auth=3D"NotApplicable" id=3D"OWA0731b9c1-c3e1-a584-aaac-3a55e7e2542=
7" class=3D"OWAAutoLink" data-loopstyle=3D"linkonly">https://doc.dpdk.org/d=
ts/test_plans/rte_flow_test_plan.html</a>) which
we want feature parity with, I think<br>
> that validation for this testing framework needs to primarily rely on =
comparing packets sent and packets<br>
> received.<br>
<br>
The unit test infrastructure validates flow rule creation and<br>
a result produced by that flow.<br>
Flow result is triggered by a packet.<br>
However, flow result validation does not always can be done by testing a pa=
cket.<br>
Unit test implements 2 flow validation methods.<br>
<br>
The first validation method tests testpmd output triggered by a test packet=
.<br>
<br>
Example: use the MODIFY_FIELD action to copy packet VLAN ID to flow TAG ite=
m.<br>
Flow tag is internal flow resource. It must be validated in DPDK applicatio=
n.<br>
<br>
Test creates 2 flow rules:<br>
<br>
Rule 1: use MODIFY_FILED to copy packet VLAN ID to flow TAG item<br>
pattern eth / vlan / end \<br>
actions modify_field op set dst_type tag ... src_type vlan_id ... / end<br>
<br>
Rule 2: validate the TAG item:<br>
pattern tag data is 0x31 ... / end actions mark id 0xaaa / rss / end<br>
<br>
The test sends a packet with VLAN ID 0x31: / Dot1Q(vlan=3D0x31) /<br>
The test matches tespmd output triggered by the packet for<br>
`FDIR matched ID=3D0xaaa`.<br>
<br>
The second validation method tests a packet after it was processed by a flo=
w.<br>
<br>
Unit test operates in a static environment. It does not compare<br>
source and target packets. The test "knows" valid target packet c=
onfiguration.<br>
<br>
Example: push VLAN header into a packet.<br>
<br>
There is a single flow rule in that example:<br>
pattern eth / end \<br>
actions of_push_vlan ethertype 0x8100 / \<br>
of_set_vlan_vid vlan_vid 3=
103 .../ port_id id 1 / end<br>
<br>
<br>
There are 2 SCAPY processes in that test: `tg` runs on peer host and<br>
sends a source packet. `vm` runs on the same host as testpmd. It validates<=
br>
incoming packet.<br>
<br>
Phase 0 prepares test packet on the `tg` and starts AsyncSniffer on the `vm=
`.<br>
Phase 1 sends the packet.<br>
Phase 2 validates the packet.<br>
The test can repeat phases 1 and 2.<br>
<br>
<br>
phase0:<br>
vm: |<br>
sniff =3D AsyncSniffer(iface=3Dpf1vf0, filter=3D'u=
dp and src port 1234')<br>
<br>
tg: |<br>
udp_packet =3D Ether(src=3D'11:22:33:44:55:66',<br=
>
&nb=
sp; dst=3D'aa:b=
b:cc:dd:ee:aa')/<br>
&nb=
sp; IP(src=3D'1.1.1.1', dst=3D'2.2.2.2')/<br>
&nb=
sp; UDP(sport=3D1234, dport=3D5678)/Raw('=3D=3D TES=
T =3D=3D')<br>
<br>
phase1: &phase1<br>
vm: sniff.start()<br>
tg: sendp(udp_packet, iface=3Dpf1)<br>
<br>
phase2: &phase2<br>
vm: |<br>
cap =3D sniff.stop()<br>
if len(cap[UDP]) > 0: cap[UDP][0][Ether].comman=
d()<br>
result:<br>
vm: vlan=3D3103<br>
<br>
>In any case, there may be some testsuites which can be written which ar=
e small<br>
>enough in scope<br>
> that validating by standard out in this way may be appropriate. I'm no=
t sure but we should keep our<br>
> options open. <br>
><br>
> 2. If the implementation overhead is not too significant for the confi=
guration step in the DTS execution a<br>
> "--fast" option like you use may be a good improvement for t=
he framework. In your mind, is the main<br>
> benefit A. reduced execution time, B. reduced user setup time (don't h=
ave to write full config file) or C.<br>
> Something else?<br>
<br>
A user must always provide test configuration.<br>
However a host can already have prepared setup before the test execution.<b=
r>
In that case a user can skip host setup phase and reduce execution time.<br=
>
<br>
><br>
> Thanks for making this available to use so we can use it as a referenc=
e in making DTS better. :) <br>
><br>
></span></div>
</body>
</html>
--_000_IA1PR12MB633208BB2EAF2B85A0B376CDA54E2IA1PR12MB6332namp_--