From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id E0E4330D for ; Thu, 12 Jun 2014 16:20:01 +0200 (CEST) Received: by mail-wg0-f46.google.com with SMTP id y10so1317377wgg.17 for ; Thu, 12 Jun 2014 07:20:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M/eQcz3N5PDJ/o5/BvjlTV8IASOhPYYpfGqVPp2mAzY=; b=G04p4c9RVrOc9Ne00BHh7hbjILiv11Injt1CSr8XNImTPDJuJLaFkL4YnoGn60wguW Uuc++IX/TK9DflwDFuVDSrL2Q+6ueQbVUznf4lYT6eNiX1Dawh5OAtyrqpsRozM6TYqg cTfyqC18II2JP1q2b156ThkoAuS9q/EdJNtwuV9YZAtAgu4Vjhn6X4LQ1K9GzuT8CqOr zFV3Dmwwg46X9GACq+HJlYr8IBAJgnELrbT3V/8XFxbXSJRdZyttzf2RO8rY+K1Id/Qe wzRIPz2wD7CkUwLTCm+feft1fIR+DzsAYYI62BZZtAO7bO9BrV3eVnojxCT8IbrERrxx uw2A== X-Gm-Message-State: ALoCoQk06UndoPxx99ccqp2gBez7gfS7TIJSyqHTJLcALGEv6Q5pkPTCW8AYvr5stM+uDyrZn36F X-Received: by 10.181.11.193 with SMTP id ek1mr7061418wid.15.1402582812125; Thu, 12 Jun 2014 07:20:12 -0700 (PDT) Received: from alcyon.dev.6wind.com (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id e11sm4334578wiw.19.2014.06.12.07.20.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 07:20:11 -0700 (PDT) Message-ID: <5399B718.4050102@6wind.com> Date: Thu, 12 Jun 2014 16:20:08 +0200 From: David Marchand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "dev@dpdk.org" References: <1401103892-17225-1-git-send-email-david.marchand@6wind.com> <1401103892-17225-4-git-send-email-david.marchand@6wind.com> <2601191342CEEE43887BDE71AB9772580EFB5EEE@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580EFB5EEE@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 12 Jun 2014 14:20:02 -0000 Hello Konstantin, Mmm, good points. I am looking into them. I will send new patches by tomorrow (hopefully). On 06/10/2014 07:23 PM, Ananyev, Konstantin wrote: > Hi David, > >> This patch adds two new functions in ethdev api to retrieve current MTU and >> 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 != ixgbe_recv_scattered_pkts) { >> + dev->rx_pkt_burst = 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 could 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 straight after it receives a packet from it. > > I wonder is the ability to change mtu on the fly (without dev_stop) is really 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 ixgbe_recv_scattered_pkts(). > Something like: > frame_size <= rx_buf_size || dev->rx_pkt_burst == ixgbe_recv_scattered_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 jumbo frames. > 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. > -- David Marchand