On Mon, Sep 30, 2019 at 11:08 AM Nipun Gupta <nipun.gu...@nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Pavan Nikhilesh Bhagavatula <pbhagavat...@marvell.com>
> > Sent: Friday, September 27, 2019 8:05 PM
> > To: Nipun Gupta <nipun.gu...@nxp.com>; Jerin Jacob Kollanukkaran
> > <jer...@marvell.com>; bruce.richard...@intel.com; Akhil Goyal
> > <akhil.go...@nxp.com>; Marko Kovacevic <marko.kovace...@intel.com>;
> > Ori Kam <or...@mellanox.com>; Radu Nicolau <radu.nico...@intel.com>;
> > Tomasz Kantecki <tomasz.kante...@intel.com>; Sunil Kumar Kori
> > <sk...@marvell.com>
> > Cc: dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v4 08/10] examples/l2fwd-event: add
> > eventdev main loop
> >
> > >>
> > >> From: Pavan Nikhilesh <pbhagavat...@marvell.com>
> > >>
> > >> Add event dev main loop based on enabled l2fwd options and
> > >eventdev
> > >> capabilities.
> > >>
> > >> Signed-off-by: Pavan Nikhilesh <pbhagavat...@marvell.com>
> > >> ---
> > >
> > ><snip>
> > >
> > >> + 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);
> > >> + }
> > >> +}
