From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A3834A2EDB for ; Mon, 30 Sep 2019 08:38:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 54D23DE3; Mon, 30 Sep 2019 08:38:38 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 3825E271 for ; Mon, 30 Sep 2019 08:38:36 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id u8so35300134iom.5 for ; Sun, 29 Sep 2019 23:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fIHjHAxBLvWEobRLeQqe4zdGkpIQEFQD5/UvBasRz5o=; b=BAjlV/UmDBt4Mx8RuloAxm6jCg4+/GFxIBr0BGKNm5FKaeXiJIYYbPMUxq5iEgJHvy 9PFbN02ELWwDvRy9xRTfp0Af2jXsZ09oLMvJu6JeUJTEIkEaReTCH2g1xYUf+T6CF2UK adSN7Ze80lG0cC04fvxd7W5krjnHMc1UZXfvvIZya47k6pRv6aNFle11JQSEbr/EUST2 0HdPMcJbMjejeR2XgV1wM13gNsO9+/eNhxmOwglztIy5CgO1OHbuQO15xe9Eb2sSvZcV TSJM2NxmoBvuFEGElhqiyUl4v/LJcHFVFGMNzYb9a0rtU7Z1RdmXB5AwYpkm7Tpg06hq dygA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fIHjHAxBLvWEobRLeQqe4zdGkpIQEFQD5/UvBasRz5o=; b=bqgCmKVyX0gnPpLNHrIYhuMjCj47eE+gBOA7bLkQs/gyHxNppa+s4O/n/nbe3YxbkL Rg81hboyKqE7OdL+XQLOBgcxG/FnES4A+5mw+nBnoBa1+AmJJetYtJOiKF9dLs4FXG6a dJ1M96gfcLSm1XYTPpMarrNdcoI0nFHUQY/B6aiTFjInIaafZRJIp4wODE8+nRAqbpRF RV0f6tSAlBQyqptOK3937Sp3CjGRI/jJNlhpsEXNEMcdZd1PLASnQTOyoXQprc8FJdeP cUHAMduJv1MxZDDIK0PKCqPWHlpQ+BvhkqLsyJCesGK14UMx+Sh/EzhiR1yNAWpJjJgp A6rw== X-Gm-Message-State: APjAAAUoqL2KUEzbFDYVDNwX7LOoSikxwjrwijstR6f/pgwTxhRDaTa0 gODWDH3n2mGbHYPgegEGCfnm8ZnPdR/H4x5uj4Y= X-Google-Smtp-Source: APXvYqxzLyreisdRdznj6yqQEM6MxTIFzHujGrPIsBKZ+yfeo+MQAzPxkiprxvUZ5L1L6AXgt5rTFQnV5kQFMEB0mK0= X-Received: by 2002:a02:7797:: with SMTP id g145mr18243741jac.60.1569825515296; Sun, 29 Sep 2019 23:38:35 -0700 (PDT) MIME-Version: 1.0 References: <20190919101346.8832-1-pbhagavatula@marvell.com> <20190924094209.3827-1-pbhagavatula@marvell.com> <20190924094209.3827-9-pbhagavatula@marvell.com> In-Reply-To: From: Jerin Jacob Date: Mon, 30 Sep 2019 12:08:24 +0530 Message-ID: To: Nipun Gupta Cc: Pavan Nikhilesh Bhagavatula , Jerin Jacob Kollanukkaran , "bruce.richardson@intel.com" , Akhil Goyal , Marko Kovacevic , Ori Kam , Radu Nicolau , Tomasz Kantecki , Sunil Kumar Kori , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 08/10] examples/l2fwd-event: add eventdev main loop 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Sep 30, 2019 at 11:08 AM Nipun Gupta wrote: > > > > > -----Original Message----- > > From: Pavan Nikhilesh Bhagavatula > > Sent: Friday, September 27, 2019 8:05 PM > > To: Nipun Gupta ; Jerin Jacob Kollanukkaran > > ; bruce.richardson@intel.com; Akhil Goyal > > ; Marko Kovacevic ; > > Ori Kam ; Radu Nicolau ; > > Tomasz Kantecki ; Sunil Kumar Kori > > > > Cc: dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v4 08/10] examples/l2fwd-event: add > > eventdev main loop > > > > >> > > >> From: Pavan Nikhilesh > > >> > > >> Add event dev main loop based on enabled l2fwd options and > > >eventdev > > >> capabilities. > > >> > > >> Signed-off-by: Pavan Nikhilesh > > >> --- > > > > > > > > > > > >> + if (flags & L2FWD_EVENT_TX_DIRECT) { > > >> + rte_event_eth_tx_adapter_txq_set(mbuf, 0); > > >> + while > > >> (!rte_event_eth_tx_adapter_enqueue(event_d_id, > > >> + port_id, > > >> + &ev, 1) > > >&& > > >> + !*done) > > >> + ; > > >> + } > > > > > >In the TX direct mode we can send packets directly to the ethernet > > >device using ethdev > > >API's. This will save unnecessary indirections and event unfolds within > > >the driver. > > > > How would we guarantee atomicity of access to Tx queues? Between cores > > as we can only use one Tx queue. > > Also, if SCHED_TYPE is ORDERED how would we guarantee flow ordering? > > The capability of MT_LOCKFREE and flow ordering is abstracted through ` > > rte_event_eth_tx_adapter_enqueue `. > > I understand your objective here. Probably in your case the DIRECT is equivalent > to giving the packet to the scheduler, which will pass on the packet to the destined device. > On NXP platform, DIRECT implies sending the packet directly to the device (eth/crypto), > and scheduler will internally pitch in. > Here we will need another option to send it directly to the device. > We can set up a call to discuss the same, or send patch regarding this to you to incorporate > the same in your series. Yes. Sending the patch will make us understand better. Currently, We have two different means for abstracting Tx adapter fast path changes, a) SINGLE LINK QUEUE b) rte_event_eth_tx_adapter_enqueue() Could you please share why any of the above schemes do not work for NXP HW? If there is no additional functionality in rte_event_eth_tx_adapter_enqueue(), you could simply call direct ethdev tx burst function pointer to make abstraction intact to avoid one more code flow in the fast path. If I guess it right since NXP HW supports MT_LOCKFREE and only atomic, due to that, calling eth_dev_tx_burst will be sufficient. But abstracting over rte_event_eth_tx_adapter_enqueue() makes application life easy. You can call the low level DPPA2 Tx function in rte_event_eth_tx_adapter_enqueue() to avoid any performance impact(We are doing the same). > > > > > @see examples/eventdev_pipeline and app/test-eventdev/test_pipeline_*. > > Yes, we are aware of that, They are one way of representing, how to build a complete eventdev pipeline. > They don't work on NXP HW. > We plan to send patches for them to fix them for NXP HW soon. > > Regards, > Nipun > > > > > > > > >> + > > >> + if (timer_period > 0) > > >> + __atomic_fetch_add(&eventdev_rsrc- > > >>stats[mbuf- > > >> >port].tx, > > >> + 1, __ATOMIC_RELAXED); > > >> + } > > >> +}