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 2CE93A0544; Tue, 11 Oct 2022 08:49:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 15BBA42C6E; Tue, 11 Oct 2022 08:49:43 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 3AAC240F19 for ; Tue, 11 Oct 2022 08:49:42 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC] net: add experimental UDP encapsulation PMD Date: Tue, 11 Oct 2022 08:47:30 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D873D0@smartserver.smartshare.dk> In-Reply-To: <20221011001016.173447-1-stephen@networkplumber.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] net: add experimental UDP encapsulation PMD Thread-Index: AdjdBd0F6acYQbg6QF2aLH30ULlPTAANRWKQ References: <20221011001016.173447-1-stephen@networkplumber.org> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Stephen Hemminger" Cc: 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 > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Tuesday, 11 October 2022 02.10 >=20 > This is a new PMD which can be useful to test a DPDK application > from another test program. The PMD binds to a connected UDP socket > and expects to receive and send raw Ethernet packets over that > socket. >=20 > This is especially useful for testing envirionments where you > can't/don't want to give the test driver program route permission. >=20 > Signed-off-by: Stephen Hemminger > --- Good idea. Multiple queues are supported, but how does the remote application steer = traffic into specific queues (for PMD RX), or identify which queue the = packet was supposed to egress on (for PMD TX)? You could use a range of UDP port numbers for that, so the second queue = uses the UDP port number following the configured port number, etc.. Or you could open for feature creep. Here are some thoughts. Add a metadata header in front of each packet - this might also allow = more advanced use in the future, e.g. the remote application could set = mbuf hash fields. Consider if this PMD somehow can be integrated with the TUN/TAP PMD or = something similar, and through that existing PMD support more advanced = NIC features towards the DPDK application, such as VLAN stripping, GRO, = etc.. =20