From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id E60D72C0F for ; Fri, 6 May 2016 10:54:40 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 06 May 2016 01:54:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,586,1455004800"; d="scan'208";a="697687766" Received: from dwdohert-dpdk.ir.intel.com ([163.33.210.69]) by FMSMGA003.fm.intel.com with ESMTP; 06 May 2016 01:54:39 -0700 To: dev@dpdk.org References: <571F4849.5030509@intel.com> <1461969005-18106-2-git-send-email-ehkinzie@gmail.com> Cc: Eric Kinzie From: Declan Doherty Message-ID: <1dba6088-f713-c894-793a-115ac10ffab6@intel.com> Date: Fri, 6 May 2016 09:50:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1461969005-18106-2-git-send-email-ehkinzie@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] bond: inherit maximum rx packet length 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: Fri, 06 May 2016 08:54:41 -0000 CC'ing follow up conversation which I accidentally took of list. -------- Forwarded Message -------- Subject: Re: [dpdk-dev] [PATCH] bond: inherit maximum rx packet length Date: Wed, 4 May 2016 14:11:53 -0400 From: Eric Kinzie To: Declan Doherty On Wed May 04 14:53:26 +0100 2016, Declan Doherty wrote: > On 29/04/16 22:36, Eric Kinzie wrote: > >On Tue Apr 26 11:51:53 +0100 2016, Declan Doherty wrote: > >>On 14/04/16 18:23, Eric Kinzie wrote: > >>> Instead of a hard-coded maximum receive length, allow the bond interface > >>> to inherit this limit from the first slave added. This allows > >>> an application that uses jumbo frames to pass realistic values to > >>> rte_eth_dev_configure without causing an error. > >>> > >>>Signed-off-by: Eric Kinzie > >>>--- > >>... > >>> > >> > >>Hey Eric, just one small thing, I think it probably makes sense to > >>return the max rx pktlen for all slaves, so as we add each slave > >>just check if that the slave being value is larger than the current > >>value. > >> > >>@@ -385,6 +389,10 @@ __eth_bond_slave_add_lock_free(uint8_t > >>bonded_port_id, uint8_t slave_port_id) > >> internals->tx_offload_capa &= dev_info.tx_offload_capa; > >> internals->flow_type_rss_offloads &= > >>dev_info.flow_type_rss_offloads; > >> > >>+ /* If new slave's max rx packet size is larger than > >>current value then override */ > >>+ if (dev_info.max_rx_pktlen > internals->max_rx_pktlen) > >>+ internals->max_rx_pktlen = dev_info.max_rx_pktlen; > >>+ > >> > >>Declan > > > >Declan, I sent an updated patch but now release that I mis-read your > >comments. Is it a good idea to change the value once it's been set? > >My patch now refuses to add a slave with a pktlen value that's smaller > >than that of the first slave. > > > >Eric > > > > Hey Eric, > > actually I think you're right, we can't change the value dynamically > once the bonded device has been configured (maybe gating on > start/stop would be sufficient), but I think we shouldn't explicitly > gate on the first slave added, as we may be bonding multiple slaves > each of which could have different max_rx_pktlens. Prior to calling > dev_configure on the bonded device it should be possible to add any > slave with any max_rx_pktlen and inherit the minimum value, but once > the bonded device has been configured we would refuse a slave with a > max_rx_pktlen value which is smaller than the current value. I think > this should then satisfy that all slaves meet the minimum > requirements published by the bonded device? > Hi, Declan. I think that would work out ok. I'll write something to that effect and send another version of the patch.