From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 42B52B62 for ; Thu, 1 Nov 2018 07:55:24 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2018 23:55:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,451,1534834800"; d="scan'208";a="277416990" Received: from kmsmsx156.gar.corp.intel.com ([172.21.138.133]) by fmsmga006.fm.intel.com with ESMTP; 31 Oct 2018 23:55:22 -0700 Received: from pgsmsx103.gar.corp.intel.com ([169.254.2.114]) by KMSMSX156.gar.corp.intel.com ([169.254.1.197]) with mapi id 14.03.0415.000; Thu, 1 Nov 2018 14:55:21 +0800 From: "Zhao1, Wei" To: Stephen Hemminger , Hideyuki Yamashita CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] Question about jumbo frame support on ixgbe Thread-Index: AQHUcPL+b4YUk9Dok0W0EDja5ij6oqU4+lwAgAEyHGCAAEue4A== Date: Thu, 1 Nov 2018 06:55:20 +0000 Message-ID: References: <20181031144907.303203-1-yong.liu@intel.com> <201810310822.w9V8MaA1017463@ccmail04.silk.ntt-tx.co.jp> <20181031084836.0e3bea7f@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [172.30.20.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Question about jumbo frame support on ixgbe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 06:55:25 -0000 Hi, Stephen Hemminger > -----Original Message----- > From: Zhao1, Wei > Sent: Thursday, November 1, 2018 11:27 AM > To: 'Stephen Hemminger' ; Hideyuki > Yamashita > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] Question about jumbo frame support on ixgbe >=20 >=20 >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen > Hemminger > > Sent: Wednesday, October 31, 2018 11:49 PM > > To: Hideyuki Yamashita > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] Question about jumbo frame support on ixgbe > > > > On Wed, 31 Oct 2018 17:22:02 +0900 > > Hideyuki Yamashita wrote: > > > > > Hi, > > > > > > I have a very basic question about jumbo frame support for ixgbe. > > > > > > I understand that some drivers support jumbo frame and if it receive > > > jumbo packet (greater than 1500 byte), it creates mbuf chains and > > > pass it to DPDK application through e.g. rte_eth_rx_burst. > > > > > > However it looks that ixgbe driver does not support jumbo frame. > > > > > > Q1. Is my understanding above correct? > > > Q2. If A1 equals YES, then are there any future plan to support > > > jumbo frame on ixgbe? > > > > > > BR, > > > Hideyuki Yamashita > > > NTT TechnoCross > > > > > > > I don't work for Intel, and haven't tried jumbo frames on ixgbe. > > The hardware does support jumbo frames. > > You might be confusing the overlapping receive offload values. > > > > The setting for using jumbo frames is in current DPDK is shown as > > available in device as: > > rx_offload_capa & DEV_RX_OFFLOAD_JUMBO_FRAME In order to > use it, this > > bit must be setn in rx_conf that is passed to rte_eth_rx_queue_setup > > >=20 > Yes, > dev_conf.rxmode.offloads bits of DEV_RX_OFFLOAD_JUMBO_FRAME > should be set to 1 when start port in API rte_eth_dev_start(). > IF you are using testpmd APP, you should set struct rte_eth_rxmode > rx_mode offloads bits of DEV_RX_OFFLOAD_JUMBO_FRAME. > but I think only set this bit of DEV_RX_OFFLOAD_JUMBO_FRAME is not > sufficient for enable this jumbo frame feature, Because in PMD code, this > flag do not set bit of IXGBE_HLREG0_JUMBOEN in register IXGBE_HLREG0, I > think this is something We need update. Correct some content above, set this bit of DEV_RX_OFFLOAD_JUMBO_FRAME can= =20 result in set bit of IXGBE_HLREG0_JUMBOEN in register IXGBE_HLREG0, but i= t still need some check of=20 packet size boundary for code safe! >=20 > > > > The feature bit that creates multiple mbuf's if necessary on receive is= : > > rx_offload_capa & DEV_RX_OFFLOAD_SCATTER Likewise to enable it, > this > > must be set in rte_eth_rx_queue_setup rx_conf. > > > > >=20 > Yes, this step can chose scatter rx function for PMD, but not MUST, detai= ls of > discussion for this is in other mail. > https://mails.dpdk.org/archives/dev/2018-November/117771.html After a double check of code, I am sure DEV_RX_OFFLOAD_SCATTER is not a mus= t choice, it is depend on=20 the relationship of max_rx_pkt_len and mbuf size, for example you set max_= rx_pkt_len to 9.5k and mbuf size to 2048, of course we need to using scatter receiving mode. >=20 >=20 >=20