From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 2C2D7231C for ; Wed, 26 Nov 2014 13:49:39 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 26 Nov 2014 05:00:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="421739386" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by FMSMGA003.fm.intel.com with ESMTP; 26 Nov 2014 04:50:44 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.93]) by IRSMSX107.ger.corp.intel.com ([169.254.10.117]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 13:00:33 +0000 From: "Wodkowski, PawelX" To: Thomas Monjalon , "Jastrzebski, MichalX K" Thread-Topic: [dpdk-dev] [PATCH v6 2/2] testpmd: add mode 4 support v6 Thread-Index: AQHQCWqkCZxTs+H3yEOLYY+kXxebj5xy1uOAgAABi6A= Date: Wed, 26 Nov 2014 13:00:32 +0000 Message-ID: References: <1417000643-26885-1-git-send-email-michalx.k.jastrzebski@intel.com> <1417000643-26885-3-git-send-email-michalx.k.jastrzebski@intel.com> <3141494.bx8cpoIdIi@xps13> In-Reply-To: <3141494.bx8cpoIdIi@xps13> Accept-Language: pl-PL, 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="iso-8859-2" 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 12:49:40 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, November 26, 2014 1:31 PM > To: Jastrzebski, MichalX K > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 2/2] testpmd: add mode 4 support v6 >=20 > 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 >=20 > 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. >=20 It is an implication of requirement that was formed on beginning of bonding= =20 implementation - bonded interface should be transparent to user app. But th= is requirement in is in collision with mode 4. It need to periodically receive= and=20 transmit frames (LACP and marker) that are not passed to user app but=20 processed/produced in background. If this will not happen in at least 10 ti= mes per second mode 4 will not work. Most of (all?) user applications do RX/TX more often than 10 times per seco= nd,=20 so this will have neglectable impact to those apps (it will have to check t= his=20 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 be th= e most transparent way to implement mode 4 without using any kind of locking inside library. Pawe=B3