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 0CD1AA0C41; Tue, 7 Sep 2021 04:25:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C796A410EB; Tue, 7 Sep 2021 04:25:06 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 69BFD40DF8; Tue, 7 Sep 2021 04:25:04 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10099"; a="281091191" X-IronPort-AV: E=Sophos;i="5.85,273,1624345200"; d="scan'208";a="281091191" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Sep 2021 19:25:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,273,1624345200"; d="scan'208";a="523554844" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga004.fm.intel.com with ESMTP; 06 Sep 2021 19:25:03 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 6 Sep 2021 19:25:02 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Mon, 6 Sep 2021 19:25:02 -0700 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.47) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Mon, 6 Sep 2021 19:25:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gt8cgATaX1xFTaJCMYRyZpRrgy6+w8SLTZJ2/OEmkzbPC8Le6SwYQKzCi/2V959YinkJJY8sXl9N+Mh0HaZ0WdYWn3HYMocI5IXp4JQetPOm/T6mnOJ7Kvhi9Je+XjrO9KvHU3F89joIepf2Kf5rG5huvhE8XFh8/rRe7sQ4HQ7SieJLOwunpPcNw00/QhhOEVjmbd9gtRfv8yNVZepIdTPbF8jMXaAkWrk6ELrHvrtngvVutliJvY9s6fyR/4lRe/0mWxeKxCUlD53q51PLo5NZtVBFtxSyXxtMwbDtKbqmWfHbNB13iXol2PUEihRKNdrSnSan9qz12EaoO2zUQg== 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; bh=JlFOb3SvJsHyMYFLFZrZL8jAS3bYXKBGcR7dHpvuvxA=; b=UZmWAkG0IuKZOmLYRL1RSzpnOBsjBVb316Uvs9fLgdGPOPsiTRbXPoSVdS7T9xhE7HZOlH9eXzYQ8AWzn88dH+48XvVFiAiL+UxCzd6EVT9vlVCEhLZ1uXWPhgNDRbdxdiU6Ssslzdgu7jJiBYgrlVuOb7oTmS4gHcqzQuCdgQBoDKXaD/hzVhRV9kY5MEkruwqK3kGyiBjpxoNvEd3Gs9y36JBbkGrhkEo358V4vjTwNZDdPswiNSmu1U7DyOizGK1vjDhDtzP4pZxUXi9OdJ6pHS2veeKhYiUks/l1DHPopbdpAV1rsdoubaPuxpvMH5O5x+niIjxQOsRPGn5IqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JlFOb3SvJsHyMYFLFZrZL8jAS3bYXKBGcR7dHpvuvxA=; b=yZx/DSDIuVbh7FQ4swiUbANJa1LZ04hbv2+vj1CnC8kf5X14SHzIGPr/JiOWZ5uHiJlrVQ0H9bG7UnaiEjDflABtgreCeSxGIDQR6Rj1i+Q3yAvc+RkC9q0Hfa2djNzv8GKSEOtZArUTUpnd7EDYYdO5KnAt+zmXoaWf8GT8uAU= Received: from DM6PR11MB3898.namprd11.prod.outlook.com (2603:10b6:5:19f::12) by DM8PR11MB5686.namprd11.prod.outlook.com (2603:10b6:8:21::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.20; Tue, 7 Sep 2021 02:25:01 +0000 Received: from DM6PR11MB3898.namprd11.prod.outlook.com ([fe80::4ca9:17cf:64c4:ca73]) by DM6PR11MB3898.namprd11.prod.outlook.com ([fe80::4ca9:17cf:64c4:ca73%4]) with mapi id 15.20.4478.025; Tue, 7 Sep 2021 02:25:01 +0000 From: "Zhang, AlvinX" To: "Li, Xiaoyun" , "Ananyev, Konstantin" CC: "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [PATCH] app/testpmd: fix random number of Tx segments Thread-Index: AQHXn9N1WoSG2Nbwd0+eSRHQlQjSUauWux4AgAALwoCAABSzAIAA9l5w Date: Tue, 7 Sep 2021 02:25:00 +0000 Message-ID: References: <20210902082013.7704-1-alvinx.zhang@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb4e7498-1522-4610-7b62-08d971a6b1c9 x-ms-traffictypediagnostic: DM8PR11MB5686: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0CDQtQdAkJj6bfXI5JnqD+7Zd72IZP50qnqk6nCTP5sJ0H2cGJb0cRALBB4SY/9ueCzj1Rc87GCqQgcwfa72AaYnT3+dL3r6dEayuq3GboR4KKSWpHkMvXkQtkIrWDnooeGllipAvU5TDmMJ+8mAw3d/TGJY/f1uY5upNqmAuXifYaAHP+znucHsQWWfZhgO86CJN/E1lAchWNrv5Vib6ug95wTaiMwPtW0JReR9KQrhM7d4fn1b23YEt2bHyTg6Qfn/N18Es66+Snv35gn12OeGTWsjlBuZZG+8P9hGPEaYgq2D5OlDErU2acDeYoOuG4Xw+CgiyQLRIJG4G+243Wh+Q1p0w/fCotgMcci1IfA8A736xt32JK69JZNrUTG87Qz6CW/WqK07gQx/HxOrEbOwXz/zmSvl9pqvcxdEPREg3W/hO4BzQcuV+Zg2jEjvFsAkrONpWgDDeYd9xQy5HaMArU1FPMz6q0eMT6ERmbC/U8VOH0gOldbffJQgCBJeN0gG0ep2nPsIIeJBsoO+XVYT7SNDfZ75XymSfzrev2oyYMZ1R5BovyuPMdCXUIExCcLM3ZWlHR9s2ykuniR+glxHJJ0dMt18PmYHZTE7Gqvi5JLTs7YzzVjWuZJC9ldWIxTb03Y0Xp4Ya1bab5x9f2nzud1rUiHICjc8KUgruAqO+fTdnvCBmJjcB6Dgd/34dKOptBhaEkJRJSlMnyPf1Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3898.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(396003)(376002)(39860400002)(346002)(83380400001)(76116006)(33656002)(66946007)(2906002)(66556008)(66446008)(38070700005)(122000001)(316002)(54906003)(110136005)(8676002)(53546011)(6506007)(450100002)(30864003)(52536014)(38100700002)(5660300002)(186003)(71200400001)(478600001)(4326008)(86362001)(6636002)(8936002)(9686003)(26005)(7696005)(66476007)(64756008)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?bCC1EkC5Umgac9LrzTOu4dLoE4XCamL6GgLRecDn2DiYZltV4fu7HuXZxU8M?= =?us-ascii?Q?cgeU6oyFWwK/X7p6R9jrwAMNW+TdFlu7RDmUNB7ZDmmG2DKPhKep6KzEGExr?= =?us-ascii?Q?r4EyNHuIawnjLuYrR4Q4APIQSPnPiQ/L94MOFxMD9MQS6Y1epMCQDq+S/VWy?= =?us-ascii?Q?Om+YT3D+l7Rh8cQ9hycemHYYnwKI3ppyA18DNT6/xO8CfbDTgpHcbZd8v9Tk?= =?us-ascii?Q?Imdijjq0Kx8h1xRmZ7hBeCPG5++XVksLcLymvMiK9ai9yWDHj5ZtSVl4T0T+?= =?us-ascii?Q?27upPRo8po5YDi3PnSUZuIKxjX0M4wjCsAOCqJl8COXYljL70lHYSR2mZf52?= =?us-ascii?Q?9hGo460BBx/QvoZ0J19kBYgqu7lC8BD+xtTJWAZh3lZ8CILspcYaBbRXnO9y?= =?us-ascii?Q?hrJWYPvQHrOOZlfhCpDJP/fvYb5Ze+32QJ+WCkjD5o1zBsTBk0aRzJuBZFlJ?= =?us-ascii?Q?2HFJYmPDIRFhojeH3edYCwmWNMayeERcsm9x3FP2bcQ4nE0EZFzJGB5wuAXz?= =?us-ascii?Q?M6MVCwn2deksB/dxSx8cFnGShznGHiCcFksdPVP6vscmoT+BUmRW/LM3XNhn?= =?us-ascii?Q?ihgTYJFT2EFBvlhylv7jK9Ulp0zv6tIWCD62S1t1afUZV1dFWVZNs+22hXPo?= =?us-ascii?Q?/2CdjMI9ToKsagTlRlJHsu76B+OtaX2FQ0dseGZV1McbqBUzM3Bu/nWrB5oX?= =?us-ascii?Q?eTY1hg3t9r18ohCX4YUNFbXMg1CTYCJFBNNtVPmE+fqSEynfJd2rDt6T7/fh?= =?us-ascii?Q?XZwTO0r1QMJqm3QGeH8Dqk+jris9miepmEw2QdGsV270L9gxjfFP2SRXWfUd?= =?us-ascii?Q?AYBLQu0TJoxKWuwvJijlWckBQId4cZLWFOMAw9c7D430+NaA0xKvo4zl4lIR?= =?us-ascii?Q?Yj4Sojb7cildRAIQdDPgs2E2dqPj3HAr4O1y8AauxoBIvTbLuXYozhWUzVNP?= =?us-ascii?Q?MjyoW3e7tU8MxCS1dRghB0QikUBa/JBFnuodWKjZi0OwX9Mt9hXI6NuYtSCT?= =?us-ascii?Q?foNOupYBvrsTLw/T58tFf/A2y5f1R9mNIkSp/dPNmJ/HNlz3N60dCY39KkBv?= =?us-ascii?Q?QtctsJA00EBITwqnK/eaF1kv6SI7hZDo4DVzLx7ig5WdulUwTfiDLB3XaI2c?= =?us-ascii?Q?hYyeIMYLiWFq8GuXVGUF4KhaHpQGod2e+DHV8dVlD3UVNdjp/0NNgeMT+XcC?= =?us-ascii?Q?mpmUp4b2SJvocBFJTJn3l1nnPmn0RBAG697FXZ1e0jLV1qbYeGqc3JqhONb0?= =?us-ascii?Q?eQBXGZ4+uHqQMhVSc8FCuA1A7vQcg37KP8XAR0x0a50yO1c+Blv/Jaeatnnm?= =?us-ascii?Q?tRc=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3898.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb4e7498-1522-4610-7b62-08d971a6b1c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2021 02:25:00.9827 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jNpFkVcELQ0Gwf7ng9b8nfUrqG0+Pw/Ei5qd7997ZUKbmbFf8VYXSYMEOwmOmIex0jUPDC6QIWG9rH55Ayjybg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR11MB5686 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix random number of Tx segments 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 Sender: "dev" > -----Original Message----- > From: Li, Xiaoyun > Sent: Monday, September 6, 2021 6:55 PM > To: Zhang, AlvinX ; Ananyev, Konstantin > > Cc: dev@dpdk.org; stable@dpdk.org > Subject: RE: [PATCH] app/testpmd: fix random number of Tx segments >=20 >=20 >=20 > > -----Original Message----- > > From: Zhang, AlvinX > > Sent: Monday, September 6, 2021 18:04 > > To: Li, Xiaoyun ; Ananyev, Konstantin > > > > Cc: dev@dpdk.org; stable@dpdk.org > > Subject: RE: [PATCH] app/testpmd: fix random number of Tx segments > > > > > -----Original Message----- > > > From: Li, Xiaoyun > > > Sent: Monday, September 6, 2021 4:59 PM > > > To: Zhang, AlvinX ; Ananyev, Konstantin > > > > > > Cc: dev@dpdk.org; stable@dpdk.org > > > Subject: RE: [PATCH] app/testpmd: fix random number of Tx segments > > > > > > Hi > > > > > > > -----Original Message----- > > > > From: Zhang, AlvinX > > > > Sent: Thursday, September 2, 2021 16:20 > > > > To: Li, Xiaoyun ; Ananyev, Konstantin > > > > > > > > Cc: dev@dpdk.org; Zhang, AlvinX ; > > > > stable@dpdk.org > > > > Subject: [PATCH] app/testpmd: fix random number of Tx segments > > > > > > > > When random number of segments in Tx packets is enabled, the total > > > > data space length of all segments must be greater or equal than > > > > the size of an Eth/IP/UDP/timestamp packet, that's total 14 + 20 + > > > > 8 + > > > > 16 bytes. Otherwise the Tx engine may cause the application to cras= h. > > > > > > > > Bugzilla ID: 797 > > > > Fixes: 79bec05b32b7 ("app/testpmd: add ability to split outgoing > > > > packets") > > > > Cc: stable@dpdk.org > > > > > > > > Signed-off-by: Alvin Zhang > > > > --- > > > > app/test-pmd/config.c | 16 +++++++++++----- > > > > app/test-pmd/testpmd.c > > > > | 5 > > > > +++++ app/test-pmd/testpmd.h | 5 +++++ app/test-pmd/txonly.c | > > > > +++++ 7 > > > > +++++ +++++-- > > > > 4 files changed, 26 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index > > > > 31d8ba1..5105b3b 100644 > > > > --- a/app/test-pmd/config.c > > > > +++ b/app/test-pmd/config.c > > > > @@ -3837,10 +3837,11 @@ struct igb_ring_desc_16_bytes { > > > > * Check that each segment length is greater or equal than > > > > * the mbuf data size. > > > > * Check also that the total packet length is greater or equal th= an the > > > > - * size of an empty UDP/IP packet (sizeof(struct rte_ether_hdr) + > > > > - * 20 + 8). > > > > + * size of an Eth/IP/UDP + timestamp packet > > > > + * (sizeof(struct rte_ether_hdr) + 20 + 8 + 16). > > > > > > I don't really agree on this. Most of the time, txonly generate > > > packets with Eth/IP/UDP. It's not fair to limit the hdr length to > > > include > > timestamp in all cases. > > > And to be honest, I don't see why you need to add > > > "tx_pkt_nb_min_segs". It's only used in txonly when > > > "TX_PKT_SPLIT_RND". So this issue is because when > > > "TX_PKT_SPLIT_RND", the > > random nb_segs is not enough for the hdr. > > > > > > But if you read txonly carefully, if "TX_PKT_SPLIT_RND", the first > > > segment length should be equal or greater than 42 (14+20+8). Because > > > when "TX_PKT_SPLIT_RND", update_pkt_header() should be called. And > > > that function doesn't deal with header in multi-segments. > > > I think there's bug here. > > > > > > So I think you should only add a check in pkt_burst_prepare() in txon= ly(). > > > if (unlikely(tx_pkt_split =3D=3D TX_PKT_SPLIT_RND) || > > > txonly_multi_flow) > > > + if (tx_pkt_seg_lengths[0] < 42) { > > > + err_log; > > > + return false; > > > + } > > > update_pkt_header(pkt, pkt_len); As above, If user have below configuration, there will no one packet be sen= t out and have lots and lots of repeated annoying logs. testpmd> set fwd txonly Set txonly packet forwarding mode testpmd> set txpkts 40,64 testpmd> set txsplit rand testpmd> start txonly packet forwarding - ports=3D1 - cores=3D1 - streams=3D4 - NUMA suppo= rt enabled, MP allocation mode: native Logical Core 2 (socket 0) forwards packets on 4 streams: RX P=3D0/Q=3D0 (socket 0) -> TX P=3D0/Q=3D0 (socket 0) peer=3D02:00:00:00= :00:00 RX P=3D0/Q=3D1 (socket 0) -> TX P=3D0/Q=3D1 (socket 0) peer=3D02:00:00:00= :00:00 RX P=3D0/Q=3D2 (socket 0) -> TX P=3D0/Q=3D2 (socket 0) peer=3D02:00:00:00= :00:00 RX P=3D0/Q=3D3 (socket 0) -> TX P=3D0/Q=3D3 (socket 0) peer=3D02:00:00:00= :00:00 txonly packet forwarding packets/burst=3D32 packet len=3D104 - nb packet segments=3D2 nb forwarding cores=3D1 - nb forwarding ports=3D1 port 0: RX queue number: 4 Tx queue number: 4 Rx offloads=3D0x0 Tx offloads=3D0x10000 RX queue: 0 RX desc=3D1024 - RX free threshold=3D32 RX threshold registers: pthresh=3D0 hthresh=3D0 wthresh=3D0 RX Offloads=3D0x0 TX queue: 0 TX desc=3D1024 - TX free threshold=3D32 TX threshold registers: pthresh=3D32 hthresh=3D0 wthresh=3D0 TX offloads=3D0x10000 - TX RS bit threshold=3D32 tx_pkt_seg_lengths[0] must bigger than 41 bytes tetx_pkt_seg_lengths[0] must bigger than 41 bytes stpmd> tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes tx_pkt_seg_lengths[0] must bigger than 41 bytes ... ... testpmd> stop Telling cores to stop... Waiting for lcores to finish... ---------------------- Forward statistics for port 0 -------------------= --- RX-packets: 0 RX-dropped: 0 RX-total: 0 TX-packets: 0 TX-dropped: 0 TX-total: 0 -------------------------------------------------------------------------= --- +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++= ++ RX-packets: 0 RX-dropped: 0 RX-total: 0 TX-packets: 0 TX-dropped: 0 TX-total: 0 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++ By the way, if multi flow was enabled, the ip header also will be updated, = so we should put the check before below codes. if (txonly_multi_flow) { uint8_t ip_var =3D RTE_PER_LCORE(_ip_var); struct rte_ipv4_hdr *ip_hdr; uint32_t addr; ip_hdr =3D rte_pktmbuf_mtod_offset(pkt, struct rte_ipv4_hdr *, sizeof(struct rte_ether_hdr)); /* * Generate multiple flows by varying IP src addr. This * enables packets are well distributed by RSS in * receiver side if any and txonly mode can be a decent * packet generator for developer's quick performance * regression test. */ addr =3D (tx_ip_dst_addr | (ip_var++ << 8)) + rte_lcore_id(); ip_hdr->src_addr =3D rte_cpu_to_be_32(addr); RTE_PER_LCORE(_ip_var) =3D ip_var; } > > > > Yes, I didn't notice the updating for the UDP header, but the bug > > first occurs in this function copy_buf_to_pkt(&pkt_udp_hdr, > sizeof(pkt_udp_hdr), pkt, > > sizeof(struct rte_ether_hdr) + > > sizeof(struct rte_ipv4_hdr)); > > not in update_pkt_header. > > > > Here we expecting users should set minimum 42 byte for first segment > > seems ok, But I think we putting the check in configuring the data > > space length of first segment is more graceful. >=20 > No. You didn't get my point. It's not graceful at all. > The segment fault will only happen when "TX_PKT_SPLIT_RND". Because the > hdr may take 2 segs while random nb_segs is only 1. > But if it's not "TX_PKT_SPLIT_RND", the current set_tx_pkt_segments() alr= eady > make sure pkt_len is enough for 42. >=20 > So the only case you need to deal with is "TX_PKT_SPLIT_RND". And since > "TX_PKT_SPLIT_RND" actually needs the first segment to be enough to conta= in > 42 bytes. > And in cmd_set_txpkts_parsed, you may not get the configuration to know i= f it > will be configured as "TX_PKT_SPLIT_RND". That's why you should check bef= ore > update_pkt_header(). >=20 > In this way, when it's NOT "TX_PKT_SPLIT_RND", it will maintain the old > behavior that hdrs may cross several segs which makes more sense. >=20 > > > > > > > > As for timestamp, maybe refer to "pkt_copy_split" in csumonly.c is > > > better? Copy the extra to the last segment if it's not enough. Not > > > sure how to deal with this issue better. > > > > > > > */ > > > > tx_pkt_len =3D 0; > > > > + tx_pkt_nb_min_segs =3D 0; > > > > for (i =3D 0; i < nb_segs; i++) { > > > > if (seg_lengths[i] > mbuf_data_size[0]) { > > > > fprintf(stderr, > > > > @@ -3849,11 +3850,16 @@ struct igb_ring_desc_16_bytes { > > > > return; > > > > } > > > > tx_pkt_len =3D (uint16_t)(tx_pkt_len + seg_lengths[i]); > > > > + > > > > + if (!tx_pkt_nb_min_segs && > > > > + tx_pkt_len >=3D (sizeof(struct rte_ether_hdr) + 20 + 8 + 16)= ) > > > > + tx_pkt_nb_min_segs =3D i + 1; > > > > } > > > > - if (tx_pkt_len < (sizeof(struct rte_ether_hdr) + 20 + 8)) { > > > > + > > > > + if (!tx_pkt_nb_min_segs) { > > > > fprintf(stderr, "total packet length=3D%u < %d - give up\n", > > > > - (unsigned) tx_pkt_len, > > > > - (int)(sizeof(struct rte_ether_hdr) + 20 + 8)); > > > > + (unsigned int) tx_pkt_len, > > > > + (int)(sizeof(struct rte_ether_hdr) + 20 + 8 + 16)); > > > > return; > > > > } > > > > > > > > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index > > > > 6cbe9ba..c496e59 100644 > > > > --- a/app/test-pmd/testpmd.c > > > > +++ b/app/test-pmd/testpmd.c > > > > @@ -232,6 +232,11 @@ struct fwd_engine * fwd_engines[] =3D { }; > > > > uint8_t tx_pkt_nb_segs =3D 1; /**< Number of segments in TXONLY > > > > packets */ > > > > > > > > +/**< Minimum number of segments in TXONLY packets to accommodate > > > > +all packet > > > > + * headers. > > > > + */ > > > > +uint8_t tx_pkt_nb_min_segs =3D 1; > > > > + > > > > enum tx_pkt_split tx_pkt_split =3D TX_PKT_SPLIT_OFF; /**< Split > > > > policy for packets to TX. */ > > > > > > > > diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index > > > > 16a3598..f5bc427 100644 > > > > --- a/app/test-pmd/testpmd.h > > > > +++ b/app/test-pmd/testpmd.h > > > > @@ -464,6 +464,11 @@ enum dcb_mode_enable extern uint16_t > > > > tx_pkt_length; /**< Length of TXONLY packet */ extern uint16_t > > > > tx_pkt_seg_lengths[RTE_MAX_SEGS_PER_PKT]; /**< Seg. lengths */ > > > > extern uint8_t tx_pkt_nb_segs; /**< Number of segments in TX > > > > packets */ > > > > + > > > > +/**< Minimum number of segments in TXONLY packets to accommodate > > > > +all packet > > > > + * headers. > > > > + */ > > > > +extern uint8_t tx_pkt_nb_min_segs; > > > > extern uint32_t tx_pkt_times_intra; extern uint32_t > > > > tx_pkt_times_inter; > > > > > > > > diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c index > > > > aed820f..27e4458 100644 > > > > --- a/app/test-pmd/txonly.c > > > > +++ b/app/test-pmd/txonly.c > > > > @@ -195,8 +195,11 @@ > > > > uint32_t nb_segs, pkt_len; > > > > uint8_t i; > > > > > > > > - if (unlikely(tx_pkt_split =3D=3D TX_PKT_SPLIT_RND)) > > > > - nb_segs =3D rte_rand() % tx_pkt_nb_segs + 1; > > > > + if (unlikely(tx_pkt_split =3D=3D TX_PKT_SPLIT_RND) && > > > > + tx_pkt_nb_segs > tx_pkt_nb_min_segs) > > > > + nb_segs =3D rte_rand() % > > > > + (tx_pkt_nb_segs - tx_pkt_nb_min_segs + 1) + > > > > + tx_pkt_nb_min_segs; > > > > else > > > > nb_segs =3D tx_pkt_nb_segs; > > > > > > > > -- > > > > 1.8.3.1