From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 0032E160 for ; Mon, 29 Oct 2018 03:22:20 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8929721BA5; Sun, 28 Oct 2018 22:22:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 28 Oct 2018 22:22:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=OM1DPN2Pb9bA+0DrP78qJx+Z6gCb9lSvpqE+AJBgi64=; b=Bsl7EfG1OyB2 WFdGKDBoWNvQr0SA8RixbTQCYPvQ2M64QRh//haZdXC5ENuhhLpqtlDq07Bisuoj wnHIQzWyO2aMuk0JsgklQl3UKBTr5FmxSFSggjPOxmXpGiWzOnwyrJWonmfB9wzZ C/p75mMzaQyxPAu/3LgPtN4khLY7TUY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=OM1DPN2Pb9bA+0DrP78qJx+Z6gCb9lSvpqE+AJBgi 64=; b=wZmDL92so4i3BSjvvrCGSbkR08uyG58MwKLMuyGHDpz95Ljmb4Hx2+amt Fz/E1WwJV2VkBeyTFl+nPD144AqgefnMH3uVgzDrysGuC/qD85vljyCWu7FAxwkp 7poyjjiTW6fHDIH97tDYX2wbId97KosibTflOPQ4krJvrwS9kSdue99mfD7v4kAs 5OXTUCfhVYWJ/RHu1qqltXVjH5Yg2QbjSMuphOCQvmnIWTl4YIN0Xm3SKL9K8xvd 1gFAiGxBTVFAs32ZKRistkrhDdaiBNCbIuC2LZPeESd7tOcOHZW8DwHxmiSRyKqH tCg0NNQGpOuoogFhtQWXkr72Z/08Q== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 83756102A0; Sun, 28 Oct 2018 22:22:18 -0400 (EDT) From: Thomas Monjalon To: "Joseph, Anoob" Cc: dev@dpdk.org, Bruce Richardson , "De Lara Guarch, Pablo" , "Ananyev, Konstantin" , Jerin Jacob , Stephen Hemminger , Narayana Prasad , Hemant Agrawal , Sunil Kumar Kori , "Rao, Nikhil" Date: Mon, 29 Oct 2018 03:22:24 +0100 Message-ID: <4007247.pNfAseMmkf@xps> In-Reply-To: <7f529e8f-a61f-3950-265e-8923efc61743@caviumnetworks.com> References: <1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com> <20180814103313.GA12412@bricha3-MOBL.ger.corp.intel.com> <7f529e8f-a61f-3950-265e-8923efc61743@caviumnetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 02:22:21 -0000 18/08/2018 11:58, Joseph, Anoob: > Hi Bruce, > > On 14-08-2018 16:03, Bruce Richardson wrote: > > On Mon, Aug 13, 2018 at 09:29:01PM +0530, Joseph, Anoob wrote: > >> Hi Bruce, > >> > >> The reason why l2fwd was chosen was to allow everyone to chip in their ideas > >> while preparing the framework. > >> This framework would be extended to other applications, hence needed enough > >> inputs before expanding to complex applications. If your suggestion is to > >> make l3fwd event driven first, I'll start looking in that direction. > > Seems good to me, if others don't have an issue with it. > > > >> As for l2fwd, I'm fine with moving event-mode additions to a new app. But > >> with the present approach, the app would run in both event mode and poll > >> mode. > >> > >> Your thoughts on renaming the existing app to l2fwd-poll and the proposed > >> app as l2fwd? > >> > >> Thanks, > >> Anoob > > I'm not sure about the name "poll", I think "ethdev" and "eventdev" should be > > the suffixes, if we want to move in that direction. > With new adapters, like crypto adapter, event device will be able to > handle multiple devices at the same time. It will be able to abstract > not just eth device but other devices too (crypto for example). For apps > like ipsec-secgw, crypto also would be abstracted with event-device. So > what should be the ideal naming convention taking into account all that? > Using "eth"& "event" won't fit in for such cases. > > Presently, mode was defined by the way packets were submitted to & > received from the device. With poll mode, device(eth, crypto etc) would > get packets directly from the core & the core would then poll for > completion. In case of event-mode, event device handles this scheduling. > Event device would submit (to all devices) and receive packets (from all > devices). Core need not poll on the device, in that case. Hence the > naming... > > Your thoughts? I think it is OK to have event mode in examples, in general. The only concern of Bruce was to keep l2fwd example simple. So for l2fwd, and only for this one, you can create a new example called l2fwd-event.