From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id A6E93231C for ; Wed, 26 Nov 2014 14:54:54 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 26 Nov 2014 06:05:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,462,1413270000"; d="scan'208";a="638424148" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga002.fm.intel.com with ESMTP; 26 Nov 2014 06:05:26 -0800 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.244]) by IRSMSX102.ger.corp.intel.com ([169.254.2.93]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 14:05:24 +0000 From: "Jastrzebski, MichalX K" To: Thomas Monjalon , "Wodkowski, PawelX" Thread-Topic: [dpdk-dev] [PATCH v6 2/2] testpmd: add mode 4 support v6 Thread-Index: AQHQCWq0BEjdkTCiWkWPCt3xdZb2qpxy1uOAgAAIMwCAAAhsgIAAA4hA Date: Wed, 26 Nov 2014 14:05:24 +0000 Message-ID: <60ABE07DBB3A454EB7FAD707B4BB1582138BD0E7@IRSMSX109.ger.corp.intel.com> References: <1417000643-26885-1-git-send-email-michalx.k.jastrzebski@intel.com> <3141494.bx8cpoIdIi@xps13> <1662294.UMylUQV4PJ@xps13> In-Reply-To: <1662294.UMylUQV4PJ@xps13> Accept-Language: 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 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v6 2/2] testpmd: add mode 4 support v6 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: Wed, 26 Nov 2014 13:54:55 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, November 26, 2014 2:31 PM > To: Wodkowski, PawelX > Cc: Jastrzebski, MichalX K; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 2/2] testpmd: add mode 4 support v6 >=20 > 2014-11-26 13:00, Wodkowski, PawelX: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > > 2014-11-26 11:17, Michal Jastrzebski: > > > > From: Pawel Wodkowski > > > > --- a/app/test-pmd/csumonly.c > > > > +++ b/app/test-pmd/csumonly.c > > > > @@ -254,8 +254,17 @@ pkt_burst_checksum_forward(struct > fwd_stream *fs) > > > > */ > > > > nb_rx =3D rte_eth_rx_burst(fs->rx_port, fs->rx_queue, pkts_burst, > > > > nb_pkt_per_burst); > > > > +#ifndef RTE_LIBRTE_PMD_BOND > > > > if (unlikely(nb_rx =3D=3D 0)) > > > > return; > > > > +#else > > > > + if (unlikely(nb_rx =3D=3D 0 && (fs->forward_timeout =3D=3D 0 || > > > > + fs->next_forward_time > rte_rdtsc()))) > > > > + return; > > > > + > > > > + if (fs->forward_timeout !=3D 0) > > > > + fs->next_forward_time =3D rte_rdtsc() + fs->forward_timeout; > > > > +#endif > > > > > > I don't understand why you need to make such change for bonding, > > > and there is no comment to explain. > > > Bonding should be a PMD like any other and shouldn't require such > change. > > > I don't know mode 4 but it seems there is a design problem here. > > > > > > > It is an implication of requirement that was formed on beginning of > bonding > > implementation - bonded interface should be transparent to user app. Bu= t > this > > requirement in is in collision with mode 4. It need to periodically rec= eive > and > > transmit frames (LACP and marker) that are not passed to user app but > > processed/produced in background. If this will not happen in at least 1= 0 > times > > per second mode 4 will not work. > > > > Most of (all?) user applications do RX/TX more often than 10 times per > second, > > so this will have neglectable impact to those apps (it will have to che= ck this > > 100ms maximum interval of rx/tx as I did in code you pointed). > > > > We had discussed all options with Declan and Bruce, and this seems to b= e > the > > most transparent way to implement mode 4 without using any kind of > locking > > inside library. >=20 > So you agree there is a design problem and you were initially trying to p= ush it > without raising the problem in the hope that nobody will see it? No, we didn't want to hide anything.=20 > It's really not the good way to work in an Open Source project. >=20 > Is there any comment in the API to explain this new constraint? No, we haven't put in the code a straight comment. I wrote about it in cove= r letter in v6 and there is also show_warnings function in patch 1/2 which will print a wa= rning to the=20 application. > Do you think we can change how Rx/Tx works in DPDK to integrate this > feature? >=20 > Actually, I think these bonding features should be implemented in a layer= on > top of DPDK. It's not the DPDK responsibility to make some protocol > processing. > Bonding was integrated with the promise that it's transparent and really > close > to the hardware ports. >=20 > Today I see we clearly need a discussion to know what should be > implemented > in DPDK. Which protocol layer is the limit? > I explained my point of view but the decision belongs to the whole > community. >=20 > -- > Thomas