From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by dpdk.org (Postfix) with ESMTP id C0509231C for ; Wed, 26 Nov 2014 14:20:10 +0100 (CET) Received: by mail-wi0-f172.google.com with SMTP id n3so12484303wiv.17 for ; Wed, 26 Nov 2014 05:31:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=HxEMKx3pqpIWV8k1AAkLOZI2P8/VEgJ9OpZMrQWXEM0=; b=laDHiWxfrQzzVBPjGdTr/ozrbuJm/k1nB4KTO+JE+6IAn2gBRB7LENgleDMqd9e904 FNn/QuUBy8DXq0O0yJJq0yVbeeEDnATLAUJcHM0DDGBEDKq+bNLh8QZrcTfV+5jjLtE2 ftitbSC7Blvgtdbwe28I3eRQTNdXqzV+Nt1+ILJ+3rn2O4C5wmF8T4u5AWFPWSX9x+N1 e1UQLq3yeXiA6/YHPOsh+j3FR4ePC8F3lpLB92w9SaI3gycdfdJpAm6Pgf4MIaPlJGPO jYYyznPjEcBDQk1NoQ+ucLtQvgezTZn2kgsI/uyWkbcryVXZ5+vqRhNKTj951Sd4je2c qb3w== X-Gm-Message-State: ALoCoQm5NuXwefrBf2tBvPbAqwBUE2uDs+aFhvR57wb3SdzMONrG1q18isdVAErPNNgEqog9pX+u X-Received: by 10.194.61.227 with SMTP id t3mr36734089wjr.96.1417008666654; Wed, 26 Nov 2014 05:31:06 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id hz9sm6393561wjb.17.2014.11.26.05.31.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Nov 2014 05:31:05 -0800 (PST) From: Thomas Monjalon To: "Wodkowski, PawelX" Date: Wed, 26 Nov 2014 14:30:41 +0100 Message-ID: <1662294.UMylUQV4PJ@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.2-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: <1417000643-26885-1-git-send-email-michalx.k.jastrzebski@intel.com> <3141494.bx8cpoIdIi@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:20:11 -0000 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 = 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 == 0)) > > > return; > > > +#else > > > + if (unlikely(nb_rx == 0 && (fs->forward_timeout == 0 || > > > + fs->next_forward_time > rte_rdtsc()))) > > > + return; > > > + > > > + if (fs->forward_timeout != 0) > > > + fs->next_forward_time = 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. But this > requirement in is in collision with mode 4. It need to periodically receive 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 10 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 check 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 be the > most transparent way to implement mode 4 without using any kind of locking > inside library. So you agree there is a design problem and you were initially trying to push it without raising the problem in the hope that nobody will see it? It's really not the good way to work in an Open Source project. Is there any comment in the API to explain this new constraint? Do you think we can change how Rx/Tx works in DPDK to integrate this feature? 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. 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. -- Thomas