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 9B362A0544; Mon, 10 Oct 2022 12:18:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8D21E40146; Mon, 10 Oct 2022 12:18:06 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 6FE8C40041 for ; Mon, 10 Oct 2022 12:18:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665397085; x=1696933085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4AWFnsd1OUgyG9sFCvLIrg0bHBOt7LoQU/vX6vcJSUc=; b=V0BU2+F28MjYM2j7uI69HHMbIS5bwECARGiIQV/PfaYOW09RrXezEGKN y4eSPrjct46B4XN2SPSc690Oylx8PUMh5K7F3nKO+DavDc7WEVlnFkl57 irv251FHfqa+lgScscnEv+dlSeNzRMU1sJScGXMpi2xk9OpRFNkgRl731 7vIESLO6tsY+obyE8g2Qw1Yhqb43cldoEn8RwGmoVT2BcKhr16anW8Afz sWfuUei3BPSblsRQI6aSMaX8DtXRikF8xdWvX/Rj7HnuHKtOpHWv0iSm0 LgHPlNW48pNCezwi+h30ha54UzLaFf0uepcXKYq6n4MUcNTXykUVE+fbh Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10495"; a="302928942" X-IronPort-AV: E=Sophos;i="5.95,173,1661842800"; d="scan'208";a="302928942" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2022 03:18:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10495"; a="801027575" X-IronPort-AV: E=Sophos;i="5.95,173,1661842800"; d="scan'208";a="801027575" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga005.jf.intel.com with ESMTP; 10 Oct 2022 03:18:04 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 10 Oct 2022 03:18:03 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) 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.2375.31 via Frontend Transport; Mon, 10 Oct 2022 03:18:03 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.177) 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.2375.31; Mon, 10 Oct 2022 03:18:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jx5m/gH7FqtpWEWIC3IgO7Dws9r+vRfLsE3u7uUEPX/sQ4vpJw9YGMX9iXV3nN6t6arT91yv4Zb+b1GYGSW3UmH4f7OXZEdfOyCGQYQOnRitvmUJyai7s2mHP3LCda+fgd5QHLzmY4uzIqQmOmwYkKuIlPgQ81emGXkjHWSZgMf00mGQL8PBec/Z3M/OkKk0ge+YBLMzfpzp+ogz73VDpoJosEtqzvWax6bYSLsKFp375doGUKR+5+r1R41EojCe9ugdSJCba9a1to9l4WZYOTpn3ObJIZxiNESbqygELwDSFwRPnsLoXjODNDYtLBtU8GWtPsLal9OhBTaUpEc89A== 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=+eGz7ba4FAv5XiP8assQKhZUgF99m3R5QabVWFn3hbY=; b=SLkPjHKlDurJ86NomCvXLq/0UCal459ueYYN+VV0cKEMZf59OWPjRkWVudU752+zuSERGbzw1dcP/xG1getGUnXwJGUkyoEUedsKr8POWkIqUJGxErqWptEYljJWBFtnd420k7pXocHSBMidfuBeGFypXtS+XYjPjIKxXvWmUHsWCz4is4Si968SvCeYzlYNgmshPv7hTvJIVjObXSTXRwDq/Al0tr9RSmD4+HYHQfBuc3AmMaozZJxG4A1OYu/ihwyV6+xhR0ZfXalHMh6c4FQ+F6xDcIalj1FLQonTMDHV/uPRuvEVr3NAYp4GHC1kpHDwapUTgVhz+U4BQzZy9g== 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 Received: from DM6PR11MB3723.namprd11.prod.outlook.com (2603:10b6:5:13f::25) by IA1PR11MB6097.namprd11.prod.outlook.com (2603:10b6:208:3d7::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.28; Mon, 10 Oct 2022 10:18:01 +0000 Received: from DM6PR11MB3723.namprd11.prod.outlook.com ([fe80::126d:f905:c1d6:dcb9]) by DM6PR11MB3723.namprd11.prod.outlook.com ([fe80::126d:f905:c1d6:dcb9%5]) with mapi id 15.20.5676.032; Mon, 10 Oct 2022 10:18:01 +0000 From: "Guo, Junfeng" To: "Li, Xiaoyun" , Ferruh Yigit , "Zhang, Qi Z" , "Wu, Jingjing" CC: "ferruh.yigit@xilinx.com" , "dev@dpdk.org" , "awogbemila@google.com" , "Richardson, Bruce" , "Lin, Xueqin" Subject: RE: [PATCH v4 7/9] net/gve: add support for Rx/Tx Thread-Topic: [PATCH v4 7/9] net/gve: add support for Rx/Tx Thread-Index: AQHY0kOGbELMWmhIykCE4qZEKC6EM64BeiuAgAQwjZCAAckkAIAABWaA Date: Mon, 10 Oct 2022 10:18:00 +0000 Message-ID: References: <20220923093829.3019525-2-junfeng.guo@intel.com> <20220927073255.1803892-1-junfeng.guo@intel.com> <20220927073255.1803892-8-junfeng.guo@intel.com> <3e2e6a34-168f-b939-2dc3-6af319d3471a@amd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.500.17 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR11MB3723:EE_|IA1PR11MB6097:EE_ x-ms-office365-filtering-correlation-id: 34590d7d-9b4a-4b43-087e-08daaaa8b5e8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: awdLDCfEn/lkOdSVlgkyWI2q7Nc+VXq1WtRDIBIIDXQ+4XrDUJ9+PP1DUziMuyB12tg6CEOHGwl3MkEMI3GfNE0U8zl2J1QnLRLRxcBIXmtNoU/WCbwTcZa8n+J7nlj4Waix+zGy9SN95ENmMTZiXF99EWChkZYBT3b9XSpjQnCYxrJ84bdWpFSH0rLFNr/lIsPmPIdi/Ah+jJeqQBqPg2X8fujnbCjlyntHSYMv6Wey0PZUzFBcgWz5+Gnje0LjTEbIz0DSE0wHsZL1JhWiabCqzu0Tgp992FCK3AmwNiSFbB07gfIkfoPuzNLPEakzjhTFoxz5MGP+Pyir/FU6tg6TB3+1l9VrinRSNp0a8bKBCm2dsqz50IrPaHPtsEykZi8FY4TB/EBfcGMhGdqPvdDvR3hSJB5VK+N5ZvBbHz+omxcf8TTSzhvlCM2PIRfgk9fvSL7fr7bVqGF+0JA/QkiQo1A3YfQi2gS194xjF4SADHg0bU8SqGc2SzL+LLWgR0o/dMdNo9e7jOVPE2cyoV2Ietu7lJO+yqFVKKvXmZMDQmcbKNRnKPHTpvTpzbW3YYwjBWzY8s39weZBRacmNLqUgvks94OAdYFb2XZW5u0QheYF/dQ8/t3CpG6VI2fLabeMohTd63J6kOjawsl2IQE6oQPERzA6WrknrnwizwtoCoPrJo58gH3onND+NRZd+s2ubQYoS3+HHh2h8h30d7lc7IJrZlXDosgYV6OgCPGrkkslxMQwcxMRZIyeqX93Muco0GzxLEZqp14oRZjIcXeGGC4dw0cRmY1clNIVgIA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3723.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(376002)(136003)(366004)(346002)(39860400002)(396003)(451199015)(53546011)(38100700002)(186003)(2906002)(71200400001)(82960400001)(966005)(122000001)(38070700005)(107886003)(4326008)(110136005)(52536014)(55016003)(83380400001)(8936002)(86362001)(8676002)(478600001)(41300700001)(66946007)(6636002)(66476007)(54906003)(66446008)(76116006)(64756008)(33656002)(6506007)(66556008)(316002)(7696005)(5660300002)(26005)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?svdId0jwdG+1gVIWbJGWG1GwUpCJ377w7Lj7W04/ID3fyVESeyQF4b4HlTxJ?= =?us-ascii?Q?Bg3RTez15VrQs0HX5Kqt9ggLG/GUoqi/dfH8ZgCauy1gIJHkVfMpFqw7U74B?= =?us-ascii?Q?lZkTRVtOIuPX0XTp5nsVh1n+S+32M+JYfmAk2NiHmyWLCZTzlCJFQH8E2dNf?= =?us-ascii?Q?/MEpEHujFVb4YDwIE/8QRrROotLNJnDyTh4/OTBcUzzARtWRUFBfXuoDqJCL?= =?us-ascii?Q?2GJJlxzfTNRoHNyIDJmvPaFA7oAXzAe5ulh/UhQsmF71Hqm7vCDC/bRMYxUr?= =?us-ascii?Q?MUd4sLBdwURG/bsh/CEZliXZ7QR9lj1fJAtpOWRxSFTX6RRDXmr1CW7fUUY/?= =?us-ascii?Q?uQkxjqrWjP5QcG8oevCxwTjH+q9U6ygES3QmzxY0RJX2sh95+AMOVXvHOCSc?= =?us-ascii?Q?I0WvO6twAK4NiefEoNVUFE2xtxOZfnp9Ljmg/mmRcNIeJqcP0i0vl8dz/yHf?= =?us-ascii?Q?kGMQe8AX4ZhI7tQv8HlOVXzVook+ArQjDbnl2W9vmWLysuqsoM8IHp3cHe/E?= =?us-ascii?Q?bqgy0uMkZsenGNaw6MbkXl/aCiYJjfUszxzXa4ShjjniJASdFZGeIVUbQqcK?= =?us-ascii?Q?vv+/pUwVYldUIeJMeodX59zuQfThDtDXaGWhDaWCq9nqZiIPkBAwLTWwg3J1?= =?us-ascii?Q?UPxeC1Bzw/AT+26bfGTb2ayUNrwPpn0uGIN9FNZyyPogsoONAdSAX/ipBb6W?= =?us-ascii?Q?j3AME5h/qw8wetmKyM9QMXLkg/sfjZNWQS4OZkcBF94mXoE5g3M49mnpNIwm?= =?us-ascii?Q?2vuAek84cWC4cWR+/eYs4ysQBNTjUEdgYgR3I6tlDFgMEztrXGyXEPVGEv3d?= =?us-ascii?Q?MaUan9hSrciKvXYuao8gaTaFjBK5oyj0Hmlx65eenjBY07U/eiFsHrAIACsO?= =?us-ascii?Q?zOp1o5LJiQtooEFboZ22goA4O/29E6cTMLjo7CYVpzP4aClskQSi0evdn/Ed?= =?us-ascii?Q?hq9T10NiseKUKSOV3os6A3IZwAO1z5pIi9E56lCnOnNl0vY8e6dvI1mErWSQ?= =?us-ascii?Q?Tp3ULeNYmizit8LPrSv/UqJeYNy4qc1imGqNfUCZmuEKpyclyVIIu5mDDk5+?= =?us-ascii?Q?+Xndsh+GX0Yyg36VJBIWGcOjMxPPa6tNy4ARrZMiLjKoP5s8VXYdbQQVIohk?= =?us-ascii?Q?MmP5oIlWddL4iAZ5V/++fd6GhN6KKSfh3nKzi3MyaqJOpmDRUff0onQGF0SV?= =?us-ascii?Q?wKqM8fEZJTX0W+tJioATRABrHNXtSq4UcM3ETdUX9Sz8UEtiMb5ROtqlizOH?= =?us-ascii?Q?oXZm5YnBFU8QI6NjhIGrN0FbEIuGq6/4nZGmGw/Z3ZBgoV5v7d2Q78Jr/HIc?= =?us-ascii?Q?6VfH76GTd7ABNjj4f4Ni3QtmNZMkzix7ir/5K6yY90cqB85N0DQrW15MfH6V?= =?us-ascii?Q?B8TXLKVuGqPu+amu1DdieO0ga9adxQFWiaNfLOi2t12oj9/JPa9Y3QyO2F2N?= =?us-ascii?Q?jqQ8YQem6whM17AZAfwReLqkqlckCEJTqRwRCHiJG2mqDNVKpcXz1L/ChTee?= =?us-ascii?Q?TBILTEJgX7yJWGNz4sXi7hvPnT7yKCSJAQBaqCv/pypKqBU10dJocg5ZAJ82?= =?us-ascii?Q?t/PrBvCCK+dPWNNXfXlx0BoiiKCnU8FldoWfjvuD?= 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: DM6PR11MB3723.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34590d7d-9b4a-4b43-087e-08daaaa8b5e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2022 10:18:00.8988 (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: RzG8DJSg+apcvNAVPNpGsH9l/tKBnzhlJ0zbw3I6ctyF4QEiBz+JoWttvH6IOb6fwHvOhq9VxcDXg1RJ9+fEyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6097 X-OriginatorOrg: intel.com 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 Thanks Xiaoyun for helping explain, it helps a lot! > -----Original Message----- > From: Li, Xiaoyun > Sent: Monday, October 10, 2022 17:40 > To: Guo, Junfeng ; Ferruh Yigit > ; Zhang, Qi Z ; Wu, > Jingjing > Cc: ferruh.yigit@xilinx.com; dev@dpdk.org; awogbemila@google.com; > Richardson, Bruce ; Lin, Xueqin > > Subject: RE: [PATCH v4 7/9] net/gve: add support for Rx/Tx >=20 > Hi >=20 > > -----Original Message----- > > From: Guo, Junfeng > > Sent: Sunday, October 9, 2022 10:15 > > To: Ferruh Yigit ; Zhang, Qi Z > > ; Wu, Jingjing > > Cc: ferruh.yigit@xilinx.com; dev@dpdk.org; Li, Xiaoyun > > ; awogbemila@google.com; Richardson, Bruce > > ; Lin, Xueqin > > Subject: RE: [PATCH v4 7/9] net/gve: add support for Rx/Tx > > > > > > > > > -----Original Message----- > > > From: Ferruh Yigit > > > Sent: Thursday, October 6, 2022 22:25 > > > To: Guo, Junfeng ; Zhang, Qi Z > > > ; Wu, Jingjing > > > Cc: ferruh.yigit@xilinx.com; dev@dpdk.org; Li, Xiaoyun > > > ; awogbemila@google.com; Richardson, > Bruce > > > ; Lin, Xueqin > > > Subject: Re: [PATCH v4 7/9] net/gve: add support for Rx/Tx > > > > > > On 9/27/2022 8:32 AM, Junfeng Guo wrote: > > > > > > > > > > > Add Rx/Tx of GQI_QPL queue format and GQI_RDA queue format. > > > > > > > > Signed-off-by: Xiaoyun Li > > > > Signed-off-by: Junfeng Guo > > > > > > <...> > > > > > > > --- a/drivers/net/gve/gve_ethdev.c > > > > +++ b/drivers/net/gve/gve_ethdev.c > > > > @@ -583,6 +583,11 @@ gve_dev_init(struct rte_eth_dev *eth_dev) > > > > if (err) > > > > return err; > > > > > > > > + if (gve_is_gqi(priv)) { > > > > + eth_dev->rx_pkt_burst =3D gve_rx_burst; > > > > + eth_dev->tx_pkt_burst =3D gve_tx_burst; > > > > + } > > > > + > > > > > > What do you think to add a log here for 'else' case, to inform user > > > why datapath is not working? > > > > Agreed, make sense! > > Currently only one queue mode (i.e., qpl mode) is supported on the GCP > env. > > Will add a log to inform this in the else case. Thanks! >=20 > This explanation is not correct. Only QPL mode is supported in GCP now. > This is env limitation but not related to the else code here. > gve_is_gqi() includes two modes GQI_QPL and GQI_RDA. And both of > these datapath is supported in rxtx. > GQI means its queue model is single queue model (txq for tx and rxq for > rx). And there're 2 ways for this queue model QPL and RDA. > QPL needs to copy packets from/to several reserved pages negotiated > with backend. RDA is just like normal device and uses PA in descs. >=20 > The datapath not supported is DQO_RDA which uses different hardware > so different queue model (split/double queue model). Tx will use txq and > tx_completion_q and Rx will use rxq and rx_completion_q. > This is not implemented in the datapath for now and will be implemented > in the future. >=20 > So if you want to add comment here. Please say "DQO_RDA is not > implemented and will be added in the future". Don't say it's not availabl= e > in GCP env which is not the reason. Okay, will add this in the coming version. Thanks! >=20 > > > > > > > > <...> > > > > > > > +uint16_t > > > > +gve_rx_burst(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t > > > nb_pkts) > > > > +{ > > > > + volatile struct gve_rx_desc *rxr, *rxd; > > > > + struct gve_rx_queue *rxq =3D rx_queue; > > > > + uint16_t rx_id =3D rxq->rx_tail; > > > > + struct rte_mbuf *rxe; > > > > + uint16_t nb_rx, len; > > > > + uint64_t addr; > > > > + > > > > + rxr =3D rxq->rx_desc_ring; > > > > + > > > > + for (nb_rx =3D 0; nb_rx < nb_pkts; nb_rx++) { > > > > + rxd =3D &rxr[rx_id]; > > > > + if (GVE_SEQNO(rxd->flags_seq) !=3D rxq->expected_se= qno) > > > > + break; > > > > + > > > > + if (rxd->flags_seq & GVE_RXF_ERR) > > > > + continue; > > > > + > > > > + len =3D rte_be_to_cpu_16(rxd->len) - GVE_RX_PAD; > > > > + rxe =3D rxq->sw_ring[rx_id]; > > > > + rxe->data_off =3D RTE_PKTMBUF_HEADROOM; > > > > + if (rxq->is_gqi_qpl) { > > > > + addr =3D (uint64_t)(rxq->qpl->mz->addr) + > > > > + rx_id * PAGE_SIZE > > > + GVE_RX_PAD; > > > > + rte_memcpy((void *)((size_t)rxe->buf_addr + > > > > + rxe- > > > >data_off), > > > > + (void *)(size_t)addr, len); > > > > > > Why a 'memcpy' is needed? Can't it DMA to mbuf data buffer? >=20 > When queue model is gpi_qpl (this is negotiated and gotten using adminq > with backend), the device needs to register a block of memory (called > page list). And tx needs to copy the packets to this memory and rx will g= et > packets from this area. > Backend will be responsible for getting(tx)/giving(rx) packets from this > memory to the device/line (We don't really know how backend does this). > Please refer to > https://www.kernel.org/doc/html/v5.4/networking/device_drivers/googl > e/gve.html. There's a bit more explanation about this queue format. >=20 > > > > Well, only qpl (queue page list) mode supported on the GCP env now. > > So the DMA may not be used in current case. >=20 > And yes, it's because GCP doesn't support GQI_RDA for now so GQI_QPL > has to be implemented. But even if GCP env supports RDA in the future, > unless they completely remove QPL support, QPL is still needed. > Because queue format/model is getting from backend through > gve_adminq_describe_device(). You may just get the QPI version. The > device can't really control which queue format to get. Thanks for the explanation! >=20 > > > > > > > > > + } > > > > + rxe->nb_segs =3D 1; > > > > + rxe->next =3D NULL; > > > > + rxe->pkt_len =3D len; > > > > + rxe->data_len =3D len; > > > > + rxe->port =3D rxq->port_id; > > > > + rxe->packet_type =3D 0; > > > > + rxe->ol_flags =3D 0; > > > > + > > > > > > As far as I can see 'sw_ring[]' filled using 'rte_pktmbuf_alloc_bulk(= )' > > > API, which should reset mbuf fields to default values, so some of the > > > assignment above can be redundant. > > > > Yes, some fields are already assigned at 'rte_pktmbuf_reset()'. > > Will remove the redundant ones in the coming version. Thanks! > > > > > > > > > + if (rxd->flags_seq & GVE_RXF_TCP) > > > > + rxe->packet_type |=3D RTE_PTYPE_L4_TCP; > > > > + if (rxd->flags_seq & GVE_RXF_UDP) > > > > + rxe->packet_type |=3D RTE_PTYPE_L4_UDP; > > > > + if (rxd->flags_seq & GVE_RXF_IPV4) > > > > + rxe->packet_type |=3D RTE_PTYPE_L3_IPV4; > > > > + if (rxd->flags_seq & GVE_RXF_IPV6) > > > > + rxe->packet_type |=3D RTE_PTYPE_L3_IPV6; > > > > + > > > > > > If you are setting packet_type, it is better to implement > > > 'dev_supported_ptypes_get()' dev_ops too, to announce host which > > > packet type parsin supporting. (+ dev_ptypes_set() dev_ops) And later > > > driver can announce "Packet type parsing" feature in .ini file. > > > > Well, on current GCP env, the APIs for supported ptypes get/set have > not > > been exposed even in the base code. The only one in the base code is > for > > the dqo mode (gve_adminq_get_ptype_map_dqo). But this also cannot > be > > used on current GCP env. We can only implement this once they are > > supported and exposed at GCP. Thanks! >=20 > You're mixing the concept again. GCP env only supports QPL is not an > excuse. > The packet type is supported even in QPL. It's just very limited to > L4_TCP/UDP and L3_IPV4/6. Ptypes_get is possible and it'll be > RTE_PTYPE_L3_IPV4/6 and RTE_PTYPE_L4_UDP/TCP. > For DQO mode you mentioned, it'll be more flexible and have more > support. I'm not sure what's your plan but it can be implemented > whenever based on the plan not GCP env availability. The base code is > there. It's just you may not be able to timely verify and debug it. >=20 > Ptype_set is not supported since the hardware doesn't support it (There's > no such adminq). Okay... no much bandwidth to implement at this point. Maybe next release, thanks!