From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 29C8A968 for ; Mon, 26 Jun 2017 16:41:33 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP; 26 Jun 2017 07:41:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,396,1493708400"; d="scan'208,217";a="1187070628" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga002.fm.intel.com with ESMTP; 26 Jun 2017 07:41:31 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.242]) by IRSMSX152.ger.corp.intel.com ([169.254.6.83]) with mapi id 14.03.0319.002; Mon, 26 Jun 2017 15:41:30 +0100 From: "Kavanagh, Mark B" To: "dev@dpdk.org" Thread-Topic: Inconsistent behaviour of rte_eth_dev_set_mtu API between ixgbe and i40e Thread-Index: AdLuh9oGnd3/2NrCS2mOBYO1K1kuYw== Date: Mon, 26 Jun 2017 14:41:30 +0000 Message-ID: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDYyNjkxNWEtNmNlNC00NWViLWFhYzAtZDk3ZTlmMThlZTFhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkdpRjNMaGljS2NHV0lqTEFlVEluK25FWHBiVENsQUdLUWJZelkrXC9GVnJBPSJ9 dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Inconsistent behaviour of rte_eth_dev_set_mtu API between ixgbe and i40e 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: Mon, 26 Jun 2017 14:41:34 -0000 Hi, In OvS-DPDK, we support single mbuf-segment jumbo frames. To date, we've supported this by creating a mempool containing mbufs of siz= e "~user-defined-MTU", and configured the NIC by crafting an rte_eth_conf s= tructure with jumbo_frame mode enabled, and the device's max_rx_pkt_len set= accordingly. e.g. static int dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int n_rxq, int n_txq) { ... struct rte_eth_conf conf =3D port_conf; if (dev->mtu > ETHER_MTU) { conf.rxmode.jumbo_frame =3D 1; conf.rxmode.max_rx_pkt_len =3D dev->max_packet_len; } else { conf.rxmode.jumbo_frame =3D 0; conf.rxmode.max_rx_pkt_len =3D 0; } In an attempt to clean this up somewhat, I recently wrote a patch for OvS-D= PDK that introduced the rte_eth_dev_set_mtu API, in place of the rte_eth_c= onf manipulation. This worked fine for Fortville/i40e PMD, but when tested = on Niantic/ixgbe, it was observed that the latter balks when a non-standard= MTU is specified. Examining the driver's source code, the source of the Niantic issue is trac= ed to the following: static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) { ... struct rte_eth_rxmode *rx_conf =3D &dev->data->dev_conf.rxmode; ... /* refuse mtu that requires the support of scattered packets when this * feature has not been enabled before. */ if (!rx_conf->enable_scatter && (frame_size + 2 * IXGBE_VLAN_TAG_SIZE > dev->data->min_rx_buf_size - RTE_PKTMBUF_HE= ADROOM)) return -EINVAL; In summary, there is an additional configuration requirement for scattered_= rx mode on Niantic; this is problematic from an application perspective, as= the rte_eth_dev_set_mtu API's behaviour is inconsistent across disparate N= ICs/PMDs. Should this be classified as a bug in DPDK? Thanks in advance, Mark