From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id C65415932 for ; Thu, 29 May 2014 13:33:29 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1WpyaW-0002KK-Cf; Thu, 29 May 2014 07:33:40 -0400 Date: Thu, 29 May 2014 07:33:35 -0400 From: Neil Horman To: "Doherty, Declan" Message-ID: <20140529113335.GB25784@hmsreliant.think-freely.org> References: <20140528174908.GB2648@localhost.localdomain> <345C63BAECC1AD42A2EC8C63AFFC3ADC13D3327C@IRSMSX101.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <345C63BAECC1AD42A2EC8C63AFFC3ADC13D3327C@IRSMSX101.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/4] Link Bonding Library 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, 29 May 2014 11:33:30 -0000 On Thu, May 29, 2014 at 10:33:00AM +0000, Doherty, Declan wrote: > -----Original Message----- > > From: Neil Horman [mailto:nhorman@tuxdriver.com] > > Sent: Wednesday, May 28, 2014 6:49 PM > > To: Doherty, Declan > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/4] Link Bonding Library > > > > On Wed, May 28, 2014 at 04:32:00PM +0100, declan.doherty@intel.com wrote: > > > From: Declan Doherty > > > > > > Initial release of Link Bonding Library (lib/librte_bond) with support > > > for bonding modes : > > > 0 - Round Robin > > > 1 - Active Backup > > > 2 - Balance l2 / l23 / l34 > > > 3 - Broadcast > > > > > Why make this a separate library? That requires exposure of yet another API to applications. Instead, why > not write a PMD that can enslave other PMD's and treat them all as a single interface? That way this all > > works with the existing API. > > > > Neil > > Hi Neil, > the link bonding device is essentially a software PMD, and as such supports all the standard PMD APIs, the only new APIs which the link bonding library introduces are for the control operations of the bonded device which are currently unsupported by the standard PMD API. Operations such as creating, adding/removing slaves, and configuring the modes of operation of the device have no analogous APIs in the current PMD API and required new ones to be created . Thats really only true in spirit, in the sense that this library transmits and receives frames like a PMD does. In practice it doesn't work and isn't architected the same way. You don't register the driver using the same method as the other PMDs, which means that using --vdev on the command line wont work for this type of device. It also implies that applications have to be made specifically aware of the fact that they are using a bonded interface (i.e. they need to call the bonding setup routines to create the bond). I would recommend: 1) Register the pmd using the PMD_DRIVER_REGISTER macro, like other PMD's 2) Use the kvargs library to support configuration via the --vdev command line option, so bonds can be created administratively, rather than just programatically 3) Separate the command api from the PMD functionality into separate libraries (use control mbufs to communicate configuration changes to the pmd). This will allow users to dynamically load the pmd functionality (without compile or run time linking requirements), and then optionally use the programatic interface (or not if they want to save memory) Regards Neil > > Declan > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. > > >