From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 7968EB0C3 for ; Tue, 10 Jun 2014 19:23:37 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 10 Jun 2014 10:23:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,1010,1392192000"; d="scan'208";a="526322906" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga001.jf.intel.com with ESMTP; 10 Jun 2014 10:23:49 -0700 Received: from irsmsx107.ger.corp.intel.com (163.33.3.99) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Jun 2014 18:23:48 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.239]) by IRSMSX107.ger.corp.intel.com ([169.254.10.208]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 18:23:48 +0100 From: "Ananyev, Konstantin" To: David Marchand , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 3/5] ethdev: add mtu accessors Thread-Index: AQHPeNYtyLDXzKm5ZUCO+s0PXC0JPJtqc/XQ Date: Tue, 10 Jun 2014 17:23:48 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580EFB5EEE@IRSMSX105.ger.corp.intel.com> References: <1401103892-17225-1-git-send-email-david.marchand@6wind.com> <1401103892-17225-4-git-send-email-david.marchand@6wind.com> In-Reply-To: <1401103892-17225-4-git-send-email-david.marchand@6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 3/5] ethdev: add mtu accessors X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:23:38 -0000 Hi David, >This patch adds two new functions in ethdev api to retrieve current MTU an= d >change MTU of a port. >These operations have been implemented for rte_em_pmd, rte_igb_pmd and >rte_ixgbe_pmd. >+ >+void ixgbe_dev_set_rx_scatter_mode(struct rte_eth_dev *dev) >+{ >+ if (dev->rx_pkt_burst !=3D ixgbe_recv_scattered_pkts) { >+ dev->rx_pkt_burst =3D ixgbe_recv_scattered_pkts; >+ /* we must ensure that this is done when we leave the >+ function */ >+ rte_wmb(); >+ } >+} I don't think it is safe to change RX function on the fly (without calling = dev_stop first). If before that ixgbe_recv_pkts_bulk_alloc() was used, then up to 32 mbufs c= ould be stored internally in the stage[], and ixgbe_recv_scattered_pkts() doesn't have a clue about them. Also with ixgbe_recv_pkts_bulk_alloc(), it could be up to rx_free_thresh RX= descriptors not armed yet with proper buffer addresses, while ixgbe_recv_scattered_pkts() doesn't expect that - it re-arms RXD str= aight after it receives a packet from it. I wonder is the ability to change mtu on the fly (without dev_stop) is real= ly needed? If so, then we probably can allow ixgbe_dev_set_mtu() to increase MTU only = if new frame size is less than RX buffer size OR that device already using ix= gbe_recv_scattered_pkts(). Something like: frame_size <=3D rx_buf_size || dev->rx_pkt_burst =3D=3D ixgbe_recv_scattere= d_pkts > +static int >+ixgbe_dev_set_mtu(struct rte_eth_dev *dev, uint16_t *mtu) >+{ >.... >+ >+ /* switch to jumbo mode if needed */ >+ if (frame_size > ETHER_MAX_LEN) { Why ETHER_MAX_LEN? If we have rx_buffer big enough, we don't need to split packets even for ju= mbo frames.=20 Shouldn't it be something like inside ixgbe_dev_rx_init(): If (mtu + 2 * IXGBE_VLAN_TAG_SIZE) > rx_buf_size) {... Same thing for igb. Konstantin =20